Understanding Java Memory Management

Technote (troubleshooting)


Problem(Abstract)

This is document 1 of a 3 document series - Diagnosing JVM Memory problems with the Maximo or TPAE application

The application fails or slows down due to the lack of memory and an increase in JVM garbage collection processes.

Symptom

Poor Performance


Cause

Lack of memory generally associated with Java coding and failure to release objects

Environment

All JVM releases

Resolving the problem


Exposing A Memory Problem Using The Maximo Debug Property MBOCount

Understanding Java Memory Management

Java memory is primarily controlled by two parameters passed to the JVM when it is started.

Xms is the amount of contiguous memory immediately allocated to the JVM when it is started. If this value is 512m then the JVM will startup and immediately allocate 512 megabytes of memory whether it needs it or not.

Xmx is the amount of memory the JVM is allowed to grow to. If this value is 1024m, the maximum amount of memory made available to the application running inside the JVM is 1 gigabyte (1000 megabytes).

In the example of minimum memory set of 512MB and maximum memory set to 1GB, Java code will run in the original allocated memory until it nears the top of the memory at which time it will allocate more until the maximum has been reached. Once Java has allocated memory to the JVM, it is generally not returned to the operating system even if the application requirement shrinks (Some JVM releases do return this memory now). Instead, it continues to run the application inside the new upper limit until a new allocation is required.

Many more parameters can be passed to control debug logging; activity frequency, and other functions but these two basic parameters (Xms and Xmx) determine the memory space available to the application.

A Java application is designed to use variables and objects (memory) and then release them when the process at hand is complete. Even though the application releases these objects, the Java JVM will not have access to the memory until a “Garbage Collection” process takes place. Java does this automatically on a timed or memory requirement basis. A typical application will show the memory availability shrink over a period of time and then become available when the garbage collection process runs. The memory graph below shows memory usage growing over time as a process uses objects and then a major garbage collection process executing that frees all unused objects.


The garbage collection process is a very processor intensive process. When monitoring processor utilization while a Java program is executing it is typical to see relatively high spikes when the process runs, however; processor utilization spikes are very short in duration with most typically taking less than a second. Users do not generally notice these spikes because they occur on the server. Users are typically on a client computer and these spikes are so short in duration they are undetectable.

Each service in Maximo uses memory in the form of variables and objects. The most notable of these is the Maximo Business Object (MBO). These MBOs are loaded into sets or groups of related objects. Each process that runs may create one or more sets of MBOs (mboset).

When a Java program does not properly release MBOs, the number of MBOs and perhaps the number of mbosets begin to grow in memory. Since the application has not officially released the objects, a garbage collection process cannot free the memory.

As the memory in use approaches the maximum available memory, the garbage collection process runs more often and when it reaches the ceiling, the garbage collection begins to run perpetually. Ultimately, all available memory is in use and the processor is 100% utilized. As JVMs approach this condition, users experience worse and worse performance until the application stops responding or the JVM finally abnormally shuts down.


Forward to - J2EE server checks for J2EE security enabled -
Exposing A Memory Problem Using The Maximo Debug Property MBOCount

Related information

Using debug properties to monitor and troubleshoot
Exposing A Memory Problem Using MBOCount
Pinpoint Memory Problems Using FetchResultLogLimit

Cross reference information
Segment Product Component Platform Version Edition
Systems and Asset Management Tivoli Asset Management for IT All
Systems and Asset Management IBM Maximo Asset Management Essentials All
Systems and Asset Management Tivoli Change and Configuration Management Database
Systems and Asset Management Tivoli Service Request Manager

Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

IBM Maximo Asset Management
System Related

Software version:

5.2, 6.0, 6.1, 6.2, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 7.1, 7.1.1, 7.1.2, 7.2, 7.2.1, 7.5

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:

1326774

Modified date:

2009-09-04

Translate my page

Machine Translation

Content navigation