previousupnext

6.2 Monitoring

LeapHeap sets the LastExecutedAt and ErrorStatus log values every time it runs, regardless of whether logging is enabled, making it easy to verify that an application is running with LeapHeap.

Logging is switched off by default to make mass deployment of LeapHeap easier. In many cases turning logging on is the first thing the administrator will do after running a new application with LeapHeap and locating the registry report.

The performance drag due to logging is slight; the highwatermark of a compartment is only updated when a fresh page of memory is committed. The metric is the number of committed pages versus the total number of pages, expressed as a percentage. A page is considered to belong to a compartment if its first byte lies within that compartment. Naturally the figure is more meaningful for large compartments with many memory pages than for small; in particular, if a compartment is smaller than one page it may contain no page boundaries at all, in which case its usage will always appear to be "0%".

The principal purpose of monitoring the highwatermark values is to detect overflow. Overflow is indicated when compartment usage is shown as 100%. If the next larger compartment is also full, it could be being filled by the overflow from the smaller compartment. Usage of only a small part of a compartment is not a problem at all as long as there is no address range shortage, and it is simply a waste of time to tune it away. Overflow should be corrected if there is no address range problem; if there is, a judgment must be made, informed by the fact that the time cost of overflow is low and the memory cost easy to calculate.

When logging is turned back off, the next invocation of the application will delete the highwatermark values. This avoids confusion about which run of the application the figures are associated with. If a record of compartment usage is desired, a screenshot should be taken.

Values in the CreateAndDestroy key are monitored to determine whether the application needs heap identifier tagging turned on. Broadly speaking, if the HeapCreateCount and HeapDestroyCount numbers creep up without limit, it does. Sometimes it is difficult to tell; for example when a print dialog is opened several HeapCreate and HeapDestroy calls are made, which can make the figures seem frightening. Also, if the application periodically loads and unloads DLLs, the C run-time library features discussed in section 1.2.1 Private Heaps and Contention may cause mass heap creation and destruction, even if the amounts of memory involved are tiny. Heap identifier tagging is to be avoided if possible. If it is site practice to reboot the server periodically, a good plan is to run initially without tagging and to monitor for memory leakage with the usual tools.

The Log key of the registry interface is where errors are reported. LeapHeap initialises early in the life of a NT process, before the user interface DLLs; it cannot use the GUI for error reporting. If an application starts up with the message box "The application failed to initialize properly ...", it is important to go straight to the ErrorMessage value to pick up the diagnostic rather than worry about the problem (even LeapHeap developers sometimes forget!). This circumstance will occur if for example there is a syntax error in the compartment sizing rules, or if LeapHeap cannot obtain all the address range it needs.

There is another class of error which cannot be reported through the registry interface because LeapHeap detects it before the registry is able to accept error reports. This happens for example if registry key HKEY_CURRENT_USER\Software does not exist, or if the creation of key HKEY_CURRENT_USER\Software\LeapHeap\application.exe fails. In that event LeapHeap causes an access violation by writing into the system area at address CCCCCCCC hex plus a small positive integer which codes the particular error. This causes the NT loader to display the same message box "The application failed to initialize properly...". However if there is a debugger available the application can be re-run under debugger control and the access violation caught. This will be of strictly limited help in that the problem can confidently be ascribed to a LeapHeap-detected error, but not any particular one. By the way, an access violation at address DDDDDDDD hex is a sign that LeapHeap has detected an error but written a diagnostic to the registry in the normal way.