IBM Support

Understanding Memory Requirements for 32 and 64 Bit Systems

Question & Answer


How should minimum (Xms) and maximum (Xmx) memory be set for a Maximo, TSRM, TAMIT, CCMDB, Control Desk or any TPAE based products?


Clarifying Documentation


Older installation guides for Maximo and TPAE/Base Services products recommended either 1 or 2 GB of memory availability for each instance of a running application server (Java Virtual Machine or JVM), depending on version. These requirements were intended for application server software and JVMs running on 32-bit operating Systems (OSs). Starting with the release of 7.5, 32 bit systems are no longer supported for production environments.

Operating systems that run in 64-bit mode can run 64 bit versions of application software (WebSphere or Oracle WebLogic) and 64-bit JVMs. 64-bit environments use 64-bit words to store variables, while 32-bit environments use 32-bit words. This means that variable space requirements on 64-bit systems can double. For this reason, it is recommended that systems running 64-bit JVMs at least double the memory settings recommended in the guides.

For 32-bit systems recommended to use 512 MB minimum and 1024 MB maximum, 64-bit systems should run 4096 MB minimum and 4096 MB maximum (Maximo and Control Desk 7.5) or 6144 MB minimum and 6144 MB maximum (Maximo and Control Desk 7.6).

For 32-bit systems recommended to use 512 MB minimum and 1536 MB maximum, 64-bit systems should run 6144 MB minimum and 6144 MB maximum.

Best Practices for System Performanc​e 7.5.x
Maximo Best Practices for System Performanc​e 7.6.x

About physical memory availability and JVM allocation recommended practices

The 64-bit memory allocation recommendations listed above are absolute minimums for 64-bit systems. Testing has shown that 64-bit systems perform best and can maximize load when memory allocation values are between 3.5 GB and 6 GB. A JVM is a program and requires resources of its own. When allocating memory to a JVM, 10% to 25% of the memory is for the JVM process itself and the remainder is for the code running in the JVM. This means that a JVM that has been allocated 4 GB may only have 3.5 GB available to the code running in the JVM. This resource memory used by the JVM is often called overhead. The recommended minimum starting memory point for 64-bit Maximo 7.5 JVMs systems is 3584 MB. Therefore we recommended that physical memory availability for each JVM be 4096 MB;0.5 GB is for JVM allocation and 512 MB is for overhead. This simplified calculation means that a 64-bit system with 16 GB physical memory can run 3 JVMs. 4 GB will be used for each JVM for allocation plus overhead and 4 GB is reserved for the OS and any required programs other than the JVMs. With Maximo 7.6, the recommended best practice is now 6144 MB (6 GB).

32-bit Windows systems are often limited to 1280 because of the way Windows addresses memory. It is sometimes possible to tune Windows and obtain JVMs that can get to 1536 in JVM allocated heap but this is the exception and not the rule. 32-bit Windows systems should assume a maximum JVM memory allocation of 1280 plus up to 512 MB physical memory for JVM overhead.

In systems where IBM recommends 1024 MB for the maximum heap allocation, the physical memory availability should be closer to 1536 MB (1.5 GB). In systems where IBM recommends 1536 MB for the maximum heap allocation, the physical memory availability should be closer to 2048 MB (2 GB). Shorting memory can lead to memory swapping and high Java garbage collection (GC) that can have a dramatic impact on performance. The same rule applies here for 64-bit systems. The memory availability should be at least doubled for 64-bit systems.

JVMs allocate memory on an as needed basis from the operating system. Generally, when the JVM starts, it will allocate the minimum memory allocated (Xms) to the application that is running. As the application requires more memory, it will allocate blocks of memory until the maximum allocation (Xmx) has been reach. The operating system will see the memory used by the JVM only as allocated by the JVM not as defined by the maximum memory parameter. This means that a JVM may show as using the minimum memory parameter when looking at the allocation through the OS but there may be more memory required as the application requires more. In some JVMs, once the JVM allocates a block of memory it is never released back to the operating system until the JVM is shut down. In these JVMs internally, the Java application may release memory back to the JVM but the JVM continues to maintain the allocated memory so from an operating system perspective the memory is in use. Some JVMs can release the memory back to the OS.

Some testing indicates that setting minimum and maximum memory allocation values to the maximum allocation value may maximize performance. Some installation guides and other documents describe setting minimum and maximum values differently. This is not a critical decision. Recommended memory settings for JVMs should be as follows:

32-bit Windows minimum/maximum = 1280/1280
32-bit Linux and Unix minimum/maximum = 2048/2048
64-bit systems minimum/maximum = 4096/4096 or 6144/6144

About over-allocating memory

It is not always recommended that more memory be allocated than recommended. Recommendations are based on application design. Allocating additional memory may not allow it to support more users but can impact performance or, in 32-bit environments can cause out of memory conditions. One of the key performance impacts is Java Garbage Collection (GC). This process relies heavily on processor power/utilization. More memory means that GC takes longer and works harder at freeing memory. If there is a requirement for more memory or additional resources the best way to provide them is through clustering and load balancing. See Using multiple JVMs to support users and functionality for more information on clustering.

See also Why can't I get a larger heap with the 32-bit JVM?

[{"Product":{"code":"SSLKT6","label":"Maximo Asset Management"},"Business Unit":{"code":"BU005","label":"IoT"},"Component":"--","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"Version Independent","Edition":""},{"Product":{"code":"SS2H8H","label":"Tivoli Asset Management"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":""},{"Product":{"code":"SSLKTY","label":"Tivoli Asset Management for IT"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":""},{"Product":{"code":"SSKTXT","label":"Tivoli Change and Configuration Management Database"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":""},{"Product":{"code":"SS6HJK","label":"Tivoli Service Request Manager"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":""},{"Product":{"code":"SSWT9A","label":"Control Desk"},"Business Unit":{"code":"BU004","label":"Hybrid Cloud"},"Component":" ","Platform":[{"code":"","label":""}],"Version":"","Edition":""}]

Document Information

Modified date:
23 June 2018