An application server is a Java based server and requires a Java virtual machine (JVM) environment to run and support the enterprise applications that run on it. As part of configuring your application server, you can configure the Classic JVM to tune performance and system resource usage. The term Classic JVM refers to the i5/OS® Java Developer Kit 6.0 JVM that is provided with the i5/OS product. Refer to the topic Tuning Java virtual machines if you are using the IBM® Techonology for Java Virtual Machine instead of the Classic JVM
Use the enablejvm command if you want to change the JVM that your application server is using
A Java runtime environment provides the execution environment for Java based applications and servers such as WebSphere® Application Server. Therefore, the Java configuration plays a significant role in determining performance, and system resource consumption, for the product and the applications that you are running on the product.
Even though JVM tuning is dependent on the JVM provider you use, there are some general tuning concepts that apply to all JVMs. These general concepts include:
The following steps provide specific instructions on how to perform the following types of tuning for each JVM. The steps do not have to be performed in any specific order.
A JIT compiler is a platform-specific compiler that generates machine instructions for each method as needed. For more information about running the JIT compiler on i5/OS, refer to the Using the Just-In-Time compiler and Just-In-Time compiler sections, of the IBM Developer Kit for Java topic, in the i5/OS Information Center.
Default: | JIT is enabled. |
Recommended: | It is recommended that you do not disable the JIT compiler, and that you enable the full JIT compiler. The os400.jit.mmi.threshold can have a significant effect on performance. For more information about the JIT compiler and the os400.jit.mmi.threshold property, refer to the Just-In-Time compiler section, of the IBM Developer Kit for Java topic, in the i5/OS Information Center. |
In some environments, such as a development environment, it is more important to optimize the startup performance of your application server rather than the runtime performance. In other environments, it is more important to optimize the runtime performance.
The Java Just-in-Time (JIT) compiler impacts whether startup or runtime performance is optimized. The initial optimization level that the compiler uses influences the length of time that is required to compile a class method, and the length of time that is required to start the server. For faster startups, reduce the initial optimization level that the compiler uses. However if you reduce the initial optimization level, the runtime performance of your applications might decrease because the class methods are now compiled at a lower optimization level.
The heap size settings control garbage collection in the JVM that is provided with i5/OS. The initial heap size is a threshold that triggers new garbage collection cycles. For example, if the initial heap size is 10 MB, a new collection cycle is triggered as soon as the JVM detects that 10 MB have been allocated since the last collection cycle.
Smaller heap sizes result in more frequent garbage collections than larger heap sizes. If the maximum heap size is reached, the garbage collector stops operating asynchronously, and user threads are forced to wait for collection cycles to complete. This situation has a significantly negative impact on performance. A maximum heap size of 0 (*NOMAX) assures that garbage collection operates asynchonously.
The maximum heap size can affect application performance. The maximum heap size specifies the maximum amount of object space that the garbage collected heap can consume. If the maximum heap size is too small, performance might decrease significantly, or the application might receive out of memory errors when the maximum heap size is reached.
Because of the complexity of determining a correct value for the maximum heap size, a value of 0, which indicates that there is no size limit, is recommended unless an absolute limit on the object space for the garbage collected heap size is required.
To determine the proper value for the maximum heap size, you must run multiple tests, because the appropriate value is different for each configuration or workload combination. If you want to prevent a run-away JVM, set the maximum heap size to a value that is larger than the size to which you expect the heap to grow, but not so large that it affects the performance of the rest of the machine.
Because you can specify a larger value for the maximum heap size without affecting performance, it is recommended that you set the largest possible value based on the resource restrictions of the JVM or the limitations of your system configuration.
After you determine an appropriate value for the maximum heap size, you might need to set up or adjust the pool in which the JVM runs. By default, application server jobs run in the base system pool, which is storage pool 2 as defined by system value WRKSYSSTS. However, you can specify a different pool. Do not set the maximum heap size to a value that is larger than 125 percent of the size of the pool in which the JVM is running. It is recommended that you run the JVM in its own memory pool with the memory permanently assigned to that pool, if possible.
If the performance adjuster is set to adjust the memory pools, that is, the system value QPFRADJ is set to a value other than 0, then it is recommended that you use the system value WRKSHRPOOL to specify a minimum size for the pool. The minimum size should be approximately equal to your garbage collected heap working set size. Setting a correct maximum heap size, and properly configuring the memory pool can prevent a JVM with a memory leak from consuming system resources, while yielding high performance.
When a JVM must run in a shared pool, it is more difficult to determine an appropriate value for the maximum heap size. Other jobs running in the pool can cause the garbage collected heap pages to be aged out of the pool. If the garbage collected heap pages are removed from the pool because of their age, the garbage collector must fault the pages back into the pool on the next garbage collection cycle because the garbage collector requires access to all of the pages in the garbage collected heap. The Classic JVM does not stop all of the JVM threads to clean the heap, you might expect that excessive page faulting causes the garbage collector to slow down and the garbage collected heap to grow. However, the operating system automatically increases the size of the heap, and the threads continue to run.
If you must set the maximum heap size to guarantee that the heap size does not exceed a given level, specify an initial heap size that is 80 - 90 percent smaller than the maximum heap size. However, specify a value that is large enough to not negatively affect performance.
To use the administrative console to configure the heap size:
You can also specify values for both fields if you need to adjust both settings.
The Initial heap size setting specifies, in megabytes, the amount of storage that is allocated for the JVM heap when the JVM starts. The Maximum heap size setting specifies, in megabytes, the maximum amount of storage that can be allocated to the JVM heap. Both of these settings have a significant effect on performance.
The default maximum heap size is 0, which indicates that there is no maximum value. It is recommended that you do not change the maximum heap size. When the maximum heap size triggers a garbage collection cycle, the garbage collection stops operating asynchronously. When garbage collection stops operating asynchronously, the application server cannot process user threads until the garbage collection cycle ends, which significantly lowers performance. See the Tuning Garbage Collection for Java and WebSphere on iSeries® topic in the i5/OS Information Center for more information on initial and maximum heap sizes.
You can also use the following command-line parameters to adjust these settings. These parameters apply to all supported JVMs and are used to adjust the minimum and maximum heap size for each application server or application server instance.
This parameter controls the initial size of the Java heap. Properly tuning this parameter reduces the overhead of garbage collection, which improves server response time and throughput. For some applications, the default setting for this option might be too low, which causes a high number of minor garbage collections.
Default | 96 MB |
Recommended | Workload specific, but higher than the default. |
Usage | Specifying -Xms256m sets the initial heap size to 256 MB. |
This parameter controls the maximum size of the Java heap. Increasing this parameter increases the memory available to the application server, and reduces the frequency of garbage collection. Increasing this setting can improve server response time and throughput. However, increasing this setting also increases the duration of a garbage collection when it does occur. This setting should never be increased above the system memory available for the application server instance. Increasing the setting above the available system memory can cause system paging and a significant decrease in performance.
Default | 0 MB |
Recommended | The default maximum heap size is 0, which indicates that there is no maximum value. |
Usage | Specifying -Xmx512m sets the maximum heap size to 512 MB. |
The optimal result for the average time between garbage collections is at least five to six times the average duration of a single garbage collection. If you do not achieve this number, the application is spending more than 15 percent of its time in garbage collection.
If the information indicates a garbage collection bottleneck, there are two ways to clear the bottleneck. The most cost-effective way to optimize the application is to implement object caches and pools. Use a Java profiler to determine which objects to target. If you can not optimize the application, try adding memory, processors and clones. Additional memory allows each clone to maintain a reasonable heap size. Additional processors allow the clones to run in parallel.
Memory leaks in the Java language are a dangerous contributor to garbage collection bottlenecks. Memory leaks are more damaging than memory overuse, because a memory leak ultimately leads to system instability. Over time, garbage collection occurs more frequently until the heap is exhausted and the Java code fails with a fatal out-of-memory exception. Memory leaks occur when an unused object has references that are never freed. Memory leaks most commonly occur in collection classes, such as Hashtable because the table always has a reference to the object, even after real references are deleted.
High workload often causes applications to crash immediately after deployment in the production environment. These application crashes if the applications are having memory leaks because the high workload accelerates the magnification of the leakage, and a memory allocation failures occur.
Memory leak problems can manifest only after a period of time, therefore, memory leaks are found easily during long-running tests. Short running tests might provide invalid indications of where the memory leaks are occurring. It is sometimes difficult to know when a memory leak is occurring in the Java language, especially when memory usage has seemingly increased either abruptly or monotonically in a given period of time. The reason it is hard to detect a memory leak is that these kinds of increases can be valid or might be the intention of the developer. You can learn how to differentiate the delayed use of objects from completely unused objects by running applications for a longer period of time. Long-running application testing gives you higher confidence for whether the delayed use of objects is actually occurring.
In many cases, memory leak problems occur by successive repetitions of the same test case. The goal of memory leak testing is to establish a big gap between unusable memory and used memory in terms of their relative sizes. By repeating the same scenario over and over again, the gap is multiplied in a very progressive way. This testing helps if the number of leaks caused by the execution of a test case is so minimal that it is hardly noticeable in one run.
You can use repetitive tests at the system level or module level. The advantage with modular testing is better control. When a module is designed to keep the private module without creating external side effects such as memory usage, testing for memory leaks is easier. First, the memory usage before running the module is recorded. Then, a fixed set of test cases are run repeatedly. At the end of the test run, the current memory usage is recorded and checked for significant changes. Remember, garbage collection must be suggested when recording the actual memory usage by inserting System.gc() in the module where you want garbage collection to occur, or using a profiling tool, to force the event to occur.
Some memory leak problems can occur only when there are several threads running in the application. Unfortunately, synchronization points are very susceptible to memory leaks because of the added complication in the program logic. Careless programming can lead to kept or not-released references. The incident of memory leaks is often facilitated or accelerated by increased concurrency in the system. The most common way to increase concurrency is to increase the number of clients in the test driver.
Heap consumption that indicates a possible leak during periods when the application server is consistently near 100 percent CPU utilization, but disappears when the workload becomes lighter or near-idle, is an indication of heap fragmentation. Heap fragmentation can occur when the JVM can free sufficient objects to satisfy memory allocation requests during garbage collection cycles, but the JVM does not have the time to compact small free memory areas in the heap to larger contiguous spaces.
Another form of heap fragmentation occurs when objects that are less than 512 bytes are freed. The objects are freed, but the storage is not recovered, resulting in memory fragmentation until a heap compaction occurs.
The Classic JVM uses concurrent (asynchronous) garbage collection. This type of garbage collection results in shorter pause times and allows application threads to continue processing requests during the garbage collection cycle.
Examining Java garbage collection gives insight to how the application is utilizing memory. Garbage collection is a Java strength. By taking the burden of memory management away from the application writer, Java applications are more robust than applications written in languages that do not provide garbage collection. This robustness applies as long as the application is not abusing objects. Garbage collection typically consumes from 5 to 20 percent of total run time of a properly functioning application. If not managed, garbage collection is one of the biggest bottlenecks for an application.
Monitoring garbage collection while a fixed workload is running, provides you with insight as to whether the application is over using objects. Garbage collection can even detect the presence of memory leaks.
You can use JVM settings to configure the type and behavior of garbage collection. When the JVM cannot allocate an object from the current heap because of lack of contiguous space, the garbage collector is invoked to reclaim memory from Java objects that are no longer being used. Each JVM vendor provides unique garbage collector policies and tuning parameters.
You can use the Verbose garbage collection setting in the administrative console to enable garbage collection monitoring. The output from this setting includes class garbage collection statistics. The format of the generated report is not standardized between different JVMs or release levels.
To ensure meaningful statistics, run a fixed workload until the application state is steady. It typically takes several minutes to reach a steady state.
You can also use object statistics in the Tivoli Performance Viewer to monitor garbage collection statistics.
To adjust your JVM garbage collection settings:
By default, the JVM unloads a class from memory whenever there are no live instances of that class left. The overhead of loading and unloading the same class multiple times, can decrease performance.
Turning off class garbage collection eliminates the overhead of loading and unloading the same class multiple times.
If you use the -noclassgc argument, whenever you redeploy an application, you should always restart the application server to clear the classes and static data from the pervious version of the application.
Default | Class garbage collection is enabled. |
Recommended | Do not disable class garbage collection. |
Usage | Specify -noclassgc to disable class garbage collection. |
If you are using the wsadmin command wsadmin -conntype none in local mode, you must set the config_consistency_check property to false before issuing this command.
Continue to gather and analyze data as you make tuning changes until you are satisfied with how the JVM is performing. Refer to the i5/OS Information Center for more general information about tuning the Classic JVM.
If your application experiences slow response times at startup, or at first touch, you might want to use the Java user classloader cache. Refer to the topic Caching classes previously loaded by a user class loader for more information.
In this information ... | IBM Redbooks, demos, education, and more(Index) Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience. This feature requires Internet access. Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof. |