Heap management arguments - #explainBestPractices mini-series

In my last article I discussed the need to manage the overall size of the Java heap that is used to store objects, In this article I dig deeper and deliver a layman's explanation of some of the key settings and why they are important. Some aspects have been simplified to make it easier to explain.

Managing the heap

As MBOs, and other objects, are used they are stored on the heap. When the code finishes using an object then a process called garbage collection frees the associated memory so it is available for use.

The process of finding objects to garbage collect is an expensive one so JVMs don't clean up old objects as soon as they become free. There are various articles that explain the general principles of garbage collection in detail.

Application designers can choose between various garbage collection policies. IBM recommend the Gencon policy for Maximo installations.

This creates two separate areas including a nursery area for objects with short lifespans. This is important because this area can be cleaned up quickly without causing user operations to be paused.

The other area is the tenured area for objects that live for longer periods of time. If the tenured area needs to be cleaned then the JVM needs to pause the JVM while it sorts the memory and cleans up unused objects.

The garbage policy determines the approach the JVM takes when it has to free memory and if it needs to pause the threads in the JVM.

The -Xmn setting controls the size of the nursery.

If this is too small then the JVM will put more of its objects in the tenured area and there is a greater risk that the JVM will need to pause the threads when the free memory is available.

If the nursery is too big then there is a greater risk that the JVM will not have enough memory for long lived objects

Vetasi advice – It is critical that these are updated when a system is being upgraded to a later version. A common mistake is to leave these at the settings for the previous version. Leaving these at the old values is creating a set of artificial barriers that restrict the JVM.

The -Xgcthreads4 setting controls the number of threads that can run to manage the memory cleanup. IBM have researched this and decided that this is the optimal number.

The JVM has its own rules that determine when a garbage collection can occur. Java code can request an explicit garbage collection but the JVM does not have to honour that request. IBM recommend disabling this function.

The -Xdisableexplicitgc option disables any explicit garbage collection requests. When the JVM loads the compiled Java class into memory it replaces any explicit garbage collection requests with code that performs no operation.

Colleagues using Weblogic installations have reported that being able to manually request a garbage collection has increased the free memory although this includes the risk that the JVM could pause the threads that the users are using.

As the JVM loads the class into memory it will need to assign blocks of memory to store the code. Maximo code is translated into server specific code (native) and it is important that the size is set correctly so that the JVM does not have to perform lots of operations to read the code because the blocks are too small.

The PermSize and MaxPermSize settings are used to manage the memory used to store objects used by the JVM.

Vetasi advice

Vetasi use an automated checking system that can confirm that an installation is using the optimal JVM settings. This tool dramatically speeds up fault investigations by identifying common problems e.g. missing settings or undersized Java heaps. Vetasi customers can raise a helpdesk call for a check although we will often run it as part of a performance investigation.

This check is offered to non-Vetasi customers as consultancy.

I have dramatically improved the performance on systems by implementing IBM's recommendations and then following up with detailed analysis of other problems. If your organisation's Maximo installation is experiencing performance problems then Vetasi offer consultancy to investigate and resolve them.

This blog series

This article is one of a series of articles to help system administrators understand the Maximo logs and the underlying architecture.

If you like this article then please share or like it.

Whilst I support the wider Maximo community and encourage the spread of knowledge, when republishing content from this blog please include the originating author along with the article or parts of.

If people do find parts of this blog coming up in blogs/newsletters/communications then please contact me directly. I’m happy to connect on LinkedIn to discuss.

Disclaimer

The postings on this blog are my own and don't necessarily represent Vetasi's positions, strategies or opinions.

The materials on this site are provided "AS IS" and the author will not be liable for any direct, indirect or incidental damages arising out or relating to any use or distribution of them. Readers are advised to test any changes/recommendations thoroughly before use