Memory Leak Applications |
 |
There are two sample applications
ML1 and Pi, that demonstrate how memory leak alerts work in HPjmeter.
ML1 demonstrates how Java Collection Leak alerts work, and Pi demonstrates
how how Array Leak alerts work.
The ML1 example uses
a simple Java program that allocates some objects, and uses a java.util.Vector object to retain references to some of
the objects, thus exhibiting the behavior of a memory-leaking application.
This application is configured to leak memory
at the rate of about 10 MB per hour. The demo application is available
from the HPjmeter installation directory:
Source: $JMETER_HOME/demo/ML1.java
Binary: $JMETER_HOME/demo/ML1.jar
Use —jar ML1.jar with the run_simple_jvmagent script to start the sample.
When measuring the sample applications, allow
considerable time for the heap to mature and stabilize, and for the
JVM agent to collect memory leak data. Eventually, you will see two
alerts:
When using the default garbage collectors and
heap size for Java HotSpot Virtual Machine 1.4.2, the detection of
a memory leak for this demonstration program occurs after about 20
minutes. This time can be substantially longer when using a different
JVM or non-standard garbage collector or heap settings.
In real situations, the detection time depends
on the maximum heap size, the size of the leak, the application running
time, and the application and load characteristics. Typically, the
detection will occur in about one hour.
Here is a Java
collection leak alert for the sample program:
Here is the heap display for the sample program:
See also Heap Usage Notification.
The Pi sample program uses a simple Java
program that allocates some arrays, thereby exhibiting the behavior
of a memory-leaking application. The demo application is available
from the HPjmeter installation directory:
Source: $JMETER_HOME/demo/Pi.java
Binary: $JMETER_HOME/demo/Pi.jar |
Use -jar Pi.jar with the run_simple_jvmagent script to start the sample.
When measuring the sample application, allow considerable time for
the heap to mature and stabilize, and for the JVM agent to collect
memory leak data. Eventually, you will see two alerts:
• Expected Out Of Memory Error Alert (page 110) with the leaking rate.
• Array Leak Locations Alert (page 112) with the leak location. |
When the default garbage collectors and
heap size for Java HotSpot Virtual Machine 1.5.0.07 are used, the
detection of a memory leak for this demonstration program occurs after
about 90 minutes. This time can be substantially longer when using
a different JVM or nonstandard garbage collector or heap settings.
In real situations, the detection time
depends on the maximum heap size, the size of the leak, the application
running time, and the application and load characteristics. Typically,
the detection will occur in about two hours.
Here is an Array Leak alert for the sample
program:
Thread Deadlock Sample |
 |
This sample application demonstrates how HPjmeter detects
deadlocked threads.
The example creates pairs of threads every 30
seconds, stopping at 50 threads, which synchronize work using shared
locks. Occasionally, the program reverses the order in which locks
are taken, eventually causing a deadlock, which generates a Thread Deadlock Alert.
The demo application is available from the HPjmeter installation
directory:
Source: $JMETER_HOME/demo/DL1.java
Binary: $JMETER_HOME/demo/DL1.jar
Use —jar DL1.jar with the run_simple_jvmagent script to start the sample.
Use the Thread Histogram display to see the thread
activity. Deadlocked threads show a solid red bar.