Use this page to view, and change the Java™ virtual machine (JVM) configuration settings of a process for an application server.
To view this administrative console page, connect to the administrative console and navigate to the Java virtual machine panel.
Application server | Click | server_name. Then, in the Server Infrastructure section, click
Deployment manager | Click System Administration > Deployment manager. Then, in the Server Infrastructure section, click |
Node agent | Click System Administration > Node agent > node_agent. Then, in the Server Infrastructure section, click |
Application server | server_name. Then, in the Server Infrastructure section, click |
Deployment manager | System Administration > Deployment manager. Then, in the Server Infrastructure section, click |
Node agent | System Administration > Node agent > node_agent. Then, in the Server Infrastructure section, click |
Specifies the standard class path in which the Java virtual machine code looks for classes.
If you need to add a classpath to this field, enter each classpath entry into a separate table row. You do not have to add a colon or semicolon at the end of each entry.
Data type | String |
Specifies bootstrap classes and resources for JVM code. This option is only available for JVM instructions that support bootstrap classes and resources.
If you need to add a classpath to this field, enter each classpath entry into a table row. You do not need to add the colon or semicolon at the end of each entry.
If you need to add multiple classpaths to this field, you can use either a colon (:) or semi-colon (;), depending on which operating system the node resides, to separate these classpaths.
Specifies whether to use verbose debug output for class loading. The default is to not enable verbose class loading.
If verbose class loading is enabled, the debug
output is sent to one of the native process logs.
Data type | Boolean |
Default | false |
Specifies whether to use verbose debug output for garbage collection. The default is not to enable verbose garbage collection.
If verbose garbage collection is enabled, the debug
output is sent to one of the native process logs.
Data type | Boolean |
Default | false |
When this field is enabled, a report is written to the output stream each time the garbage collector runs. This report should give you an indication of how the Java garbage collection process is functioning.
83.29/3724.32 * 100 = 2.236 percent
If you are spending more than 5 percent of your time in garbage collection and if garbage collection is occurring frequently, you might need to increase your Java heap size.
To determine if the allocated heap is growing, look at the percentage of the heap that is remains unallocated after each garbage collection cycle, and verify that the percentage is not continuing to decline. If the percentage of free space continues to decline you are experiencing a gradual growth in the heap size from garbage collection to garbage collection. This situation might indicate that your application has a memory leak.
On the z/OS platform, you can also issue
the MVS™ console command, modify display,
jvmheap, to display JVM heap information. In addition, you
can check the server activity and interval SMF records. The JVM heap
size is also made available to PMI and can be monitored using the Tivoli® Performance
Viewer.
Specifies whether to use verbose debug output for native method invocation. The default is not to enable verbose Java Native Interface (JNI) activity.
Data type | Boolean |
Default | false |
Specifies, in megabytes, the initial heap size available to the JVM code. If this field is left blank, the default value is used.
For z/OS, the default initial heap
size for the controller is 48 MB, and the default initial heap size
for the servant is 128 MB. These default values apply for both 31-bit
and 64-bit configurations.
For IBM i and distributed platforms, the
default initial heap size is 50 MB.
Increasing this setting can improve startup. The number of garbage collection occurrences are reduced and a 10 percent gain in performance is achieved.
Increasing the size of the Java heap continues to improves throughput until the heap becomes too large to reside in physical memory. If the heap size exceeds the available physical memory, and paging occurs, there is a noticeable decrease in performance.
Specifies, in megabytes, the maximum heap size that is available to the JVM code. If this field is left blank, the default value is used.
The default maximum heap size is 256 MB. This default value applies for both 31-bit and 64-bit configurations.
Increasing the maximum heap size setting can improve startup. When you increase the maximum heap size, you reduce the number of garbage collection occurrences with a 10 percent gain in performance.
Increasing this setting usually improves throughput until the heap becomes too large to reside in physical memory. If the heap size exceeds the available physical memory, and paging occurs, there is a noticeable decrease in performance. Therefore, it is important that the value you specify for this property allows the heap to be contained within physical memory.
To prevent paging, specify a value for this property
that allows a minimum of 256 MB of physical memory for each processor
and 512 MB of physical memory for each application server. If processor
utilization is low because of paging, increase the available memory,
if possible, instead of increasing the maximum heap size. Increasing
the maximum heap size might decrease performance rather than improving
performance.
Specifies whether to use HProf profiler support. To use another profiler, specify the custom profiler settings using the HProf Arguments setting. The default is not to enable HProf profiler support.
If you set the Run HProf property to true, then you must specify command-line profiler arguments as values for the HProf Arguments property.
Data type | Boolean |
Default | false |
Specifies command-line profiler arguments to pass to the JVM code that starts the application server process. You can specify arguments when HProf profiler support is enabled.
HProf arguments are only required if the Run HProf property is set to true.
Specifies whether to run the JVM in debug mode. The default is to not enable debug mode support.
If you set the Debug mode property to true, then you must specify command-line debug arguments as values for the Debug arguments property.
Data type | Boolean |
Default | false |
Specifies command-line debug arguments to pass to the JVM code that starts the application server process. You can specify arguments when the Debug mode property is set to true.
If you enable debugging on multiple application servers on the same node, verify that the same value is not specified for the address argument. The address argument defines the port that is used for debugging. If two servers, for which debugging is enabled, are configured to use the same debug port, the servers might fail to start properly. For example, both servers might still be configured with the debug argument address=7777, which is the default value for the debug address argument.
Data type | String |
Units | Java command-line arguments |
Specifies command-line arguments to pass to the Java virtual machine code that starts the application server process.
Specify hotRestartSync if you want to enable the hot restart sync feature of the synchronization service. This feature indicates to the synchronization service that the installation is running in an environment where configuration updates are not made when the deployment manager is not active. Therefore, the service does not have to perform a complete repository comparison when the deployment manager or node agent servers restart. Enabling this feature improves the efficiency of the first synchronization operation after the deployment manager or a node agent restarts, especially for installations that include mixed release cells, use several nodes, and run several applications.
This argument only applies for z/OS. Specify the -Dcom.ibm.CORBA.RequestTimeout= timeout_interval argument to set the timeout period for responding to requests sent from the client. This argument uses the -D option. timeout_interval is the timeout period in seconds. If your network experiences extreme latency, specify a large value to prevent timeouts. If you specify a value that is too small, an application server that participates in workload management can time out before it receives a response.
Specify this argument only if your application is experiencing problems with timeouts. There are no recommended values for this argument.
This argument only applies for z/OS. Specify the -Dcom.ibm.websphere.wlm.unusable.interval= timeout_interval argument to change the value of the com.ibm.websphere.wlm.unusable.interval property when the workload management state of the client is refreshing too soon or too late. This property specifies, in seconds, the amount of time that the workload management client run time waits after it marks a server as unavailable before it attempts to contact the server again. This argument uses the -D option. . The default value is 300 seconds. If the property is set to a large value, the server is marked as unavailable for a long period of time. This prevents the workload management refresh protocol from refreshing the workload management state of the client until after the time period has ended.
This argument only applies for z/OS. Specify the -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl= argument to indicate that storage for individual direct byte buffers should be released as soon as the buffer is no longer needed. The only supported value for this argument is com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl.
-Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
On the z/OS platform, you also need to
specify this argument if you specify thezaioFreeInitialBuffers custom
property for a TCP channel to have the channel release the initial
read buffers used on new connections as soon as these buffers are
no longer needed for the connection.
You can use -Dcom.ibm.server.allow.sigkill=true to allow the node agent process to use the terminate method of a process when the stop method does not complete within the time interval specified for the Ping interval. This setting is useful when the node agent is monitoring an application server and loses contact with that application server.
When the monitoring policy for the application server allows the node agent to restart the application server because automatic restart is enabled for the application server, the node agent executes the stop method on the application server process. During stop processing, the node agent monitors the application server and if the application server does not stop within the time interval specified for the Ping interval, and this argument is set to true, the node agent executes the terminate method on the application server process to stop the application server process.
If you do not specify this argument, or if the argument is set to false, the node agent continues to monitor the stop process, but does not try to restart the application server.
To use the administrative console to enable this argument, click System Administration > Node agents > nodeagent_name > Java & Process Management > Process Definition > Java Virtual Machine > Generic JVM Arguments
Specifies whether SIP compliance checking is enabled in the SIP proxy server. SIP compliance checking ensures that the SIP messages conform to the Session Initiation Protocol standard. When this property is set to true, SIP compliance checking is enabled.
Java HotSpot Technology in Java SE 6 uses an adaptive JVM containing algorithms that, over time, optimize how the byte code performs. The JVM runs in two modes, -server and -client. In most cases, use -server mode, which produces more efficient run-time performance over extended lengths of time.
If you use the default -client mode, the server startup time is quicker and a smaller memory footprint is created. However, this mode lowers extended performance. Use the -server mode, which improves performance, unless server startup time is of higher importance than performance. You can monitor the process size, and the server startup time to check the performance difference between using the -client and -server modes.
Specify-Xverify:none if you want to skip the class verification stage during class loading . Using -Xverify:none disables Java class verification, which can provide a 10-15 percent improvement in startup time. However corrupted or invalid class data is not detected when this argument is specified. If corrupt class data is loaded, the JVM might behave in an unexpected manner, or the JVM might fail.
Specify-Xnoclassgc if you want to disable class garbage collection. This argument results in more class reuse and slightly improved performance. However, the resources owned by these classes remain in use even when the classes are not being called.
You can use the verbose:gc configuration setting if you want to monitor garbage collection. You can use the resulting output to determine the performance impact of reclaiming these resources.
If you specify the -Xnoclassgc 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.
Specify -Xgcthreads if you want to use several garbage collection threads at one time. This garbage collection techniques is known as parallel garbage collection. This argument is valid only for the IBM Developer Kit.
When entering this value in the Generic JVM arguments field, also enter the number of processors that are running on your machine.
-Xgcthreads<number of processors>
-Xgcthreads5 is an example of specifying -Xgcthreads with 5 processors.
gotchaOn a node with n processors, the default number of threads is n.
Specify -Xnocompactgc if you want to disable heap compaction. Heap compaction is the most expensive garbage collection operation. If you are using the IBM Developer Kit, you should avoid heap compaction. If you disable heap compaction, you eliminate all associated overhead.
Specify-Xgcpolicy to set the garbage collection policy. This argument is valid only for the IBM Developer Kit.
Set this argument to optthruput if you want to optimize throughput and it does not create a problem if long garbage collection pauses occur. This is the default parameter, recommended setting.
Set this argument to gencon, if you are using a generational garbage collector. The generational schema attempts to achieve high throughput along with reduced garbage collection pause times. To accomplish this goal, the heap is split into new and old segments. Long lived objects are promoted to the old space while short-lived objects are garbage collected quickly in the new space. The gencon policy provides significant benefits for many applications. However, it is not suited for all applications, and is typically more difficult to tune.
Set this argument to optavgpause, if you want concurrent marking used to track application threads starting from the stack before the heap becomes full. When this parameter is specified, the garbage collector pauses become uniform and long pauses are not apparent. However, using this policy reduces throughput because threads might have to do extra work.
Set this argument to subpool, if you want to increase performance on multiprocessor systems, that commonly use more then eight processors. This policy is only available on IBM System i, System p, and System z processors. The subpool policy is similar to the optthruput policy except that the heap is divided into subpools that provide improved scalability for object allocation.
The Java Platform, Standard Edition 6 (Java SE 6) has generation garbage collection, which allows separate memory pools to contain objects with different ages. The garbage collection cycle collects the objects independently from one another depending on age. With additional parameters, you can set the size of the memory pools individually. To achieve better performance, set the size of the pool containing objects that have short life cycles, such that the objects in the pool are not kept through more then one garbage collection cycle. Use the NewSize and MaxNewSize parameters to specify the size of the new generation pool.
-XX:NewSize=lower_bound -XX:MaxNewSize=upper_bound -XX:SurvivorRatio=new_ratio_size
Alternatively, you could set 50% to 60% of the total heap size to a new generation pool.
Specify-Xminf if you want to change the minimum free heap size percentage. The heap grows if the free space is below the specified amount. In reset enabled mode, this argument specifies the minimum percentage of free space for the middleware and transient heaps. The valued specified for this argument is a floating point number, 0 through 1. The default is .3 (30 percent).
Specify the-Xshareclasses:none argument to disable the share classes option for a process. The share classes option, which is available with Java SE 6, lets you share classes in a cache. Sharing classes in a cache can improve startup time and reduce memory footprint. Processes, such as application servers, node agents, and deployment managers, can use the share classes option.
If you use this option, you should clear the cache when the process is not in use. To clear the cache, either call the app_server_root/bin/clearClassCache.bat/sh utility or stop the process and then restart the process.
Use the -XXallowvmshutdown:false argument to revert to a previous behavior for the JVM that is not correct. Java 5.0 SR10 and Java 6 SR5 correct issues in which the Java Virtual Machine (JVM) does not shut down correctly. If you have an application that depends on the old behavior, you can revert to the previous behavior by adding the this argument to the Generic JVM arguments section.
Data type | String |
Units | Java command-line arguments |
Specifies a full path name for an executable JAR file that the JVM code uses.
Data type | String |
Units | Path name |
Specifies whether to disable the just-in-time (JIT) compiler option of the JVM code.
If you disable the JIT compiler, throughput decreases noticeably. Therefore, for performance reasons, keep JIT enabled.
Data type | Boolean |
Default | false (JIT enabled) |
Recommended | JIT enabled |
Specifies JVM settings for a given operating system.
When the process starts, the process uses the JVM settings that are specified for the node as the JVM settings for the operating system.