HPjmeter constantly monitors all open sessions
and analyzes the heap size after each garbage collection. It tries
to detect a longtime, increasing trend in the heap sizes. If it determines
that a dependency exists between elapsed time and the heap size, and
that the heap size is always greater than a certain linear function
of time, it calculates a potential memory leak rate.
The next figure shows the heap size after each
garbage collection plotted over time, using the standard Garbage Collections display.
The metrics show that as time passes, the lowest post-garbage collection
heap size increases, indicating that a growing area of heap is un-collectible.
The uncollectible and retained memory eventually
fills the heap, as shown in this Heap Monitor display.
HPjmeter uses the long term linear upward trends
in the heap size after garbage collections to calculate the presence
of memory leaks.
Short-term increases in heap size are normal. HPjmeter measures
this rate in MB/hour.
HPjmeter does not report a leak in situations
in which the heap size increase is only temporary, or in situations
in which the slope of the fitted line is too small to raise an alarm.
However, sometimes a healthy Java application
is diagnosed with a memory leak. When the heap size returns to its
previous range, such an erroneous diagnosis is revoked, reverting
to its original state.
Leak detection accuracy improves over time, so
if a memory leak alarm fluctuates on and off, or in value, you should
base your analysis on the present alarm state.
With high leak-rate, you can consider having the
IT administrator start another JVM and stop the old one in a controlled
way, in a clustered environment, when the garbage collection percentage
becomes excessive. What is considered excessive depends more on the
rate of change of garbage collection percentage or the estimated number
of minutes before the heap will run out.