Java virtual machine settings

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:

For the z/OS platform:
Application server Click Servers > Application Servers > server1. Then, under Server Infrastructure, click > Process Definition, select Control or Servant, and then click Java Virtual Machine.
Deployment manager Click System Administration > Deployment Manager. Then, under Server Infrastructure, click Process definition > Control > Java Virtual Machine
Node agent Click System Administration > Node Agent > nodeagent. Then, under Server Infrastructure, click Process definition > Control > Java Virtual Machine

Configuration tab

Classpath

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.

Enter each classpath entry into a table row. You do not need to add the colon or semicolon at the end of each entry.

The only classpaths that should be added to this field are the ones that specify the location of the following items:
  • An inspection or monitoring tool to your system.
  • JAR files for a product that runs on top of this product.
  • JVM diagnostic patches or fixes.
Processing errors might occur if you add classpaths to this field that specify the location of the following items:
  • JAR files for resource providers, such as DB2. The paths to these JAR files should be added to the relevant provider class paths.
  • A user JAR file that is used by one or more of the applications that you are running on the product. The path to this type of JAR file should be specified within each application that requires that JAR file, or in server-associated shared libraries.
  • An extension JAR file. If you need to add an extension JAR file to your system, you should use the ws.ext.dirs JVM custom property to specify the absolute path to this JAR file. You can also place the JAR file in the WAS_HOME/lib/ext/ directory, but using the ws.ext.dirs JVM custom property is the recommended approach for specifying the path to an extension JAR file.
Data type String

Boot classpath

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 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.

The only classpaths that should be added to this field are the ones that specify the location of the following items:
  • An inspection or monitoring tool to your system.
  • JAR files for a product that runs on top of this product.
  • JVM diagnostic patches or fixes.
Processing errors might occur if you add classpaths to this field that specify the location of the following items:
  • JAR files for resource providers. such as DB2. The paths to these JAR files should be added to the relevant provider class paths.
  • A user JAR file that is used by one or more of the applications that you are running on the product. The path to this type of JAR file should be specified within each application that requires that JAR file, or in server-associated shared libraries.
  • An extension JAR file. If you need to add an extension JAR file to your system, you should use the ws.ext.dirs JVM custom property to specify the absolute path to this JAR file. You can also place the JAR file in the WAS_HOME/lib/ext/ directory, but using the ws.ext.dirs JVM custom property is the recommended approach for specifying the path to an extension JAR file.
Data type String

Verbose class loading

Specifies whether to use verbose debug output for class loading. The default is not to enable verbose class loading.

Data type Boolean
Default false

Verbose garbage collection

Specifies whether to use verbose debug output for garbage collection. The default is not to enable verbose garbage collection.

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 idea of what is going on with Java garbage collection.

Key things to look for in a verboseGC report are:
  • Time spent in garbage collection.
    Ideally, you want to be spending less than 5% of the time in GC. To determine percentage of time spent in GC, divide the time it took to complete the collection by the time since the last AF and multiply the result by 100. For example,
    83.29/3724.32 * 100 = 2.236%
    
    

    If you are spending more than 5% of your time in GC and if GC is occurring frequently, you may need to increase your Java heap size.

  • Growth in the allocated heap.

    To determine this, look at the %free. You want to make sure the number is not continuing to decline. If the %free continues to decline you are experiencing a gradual growth in allocated heap from GC to GC which could indicate that your application has a memory leak.

You can also use the MVS console command, modify display, jvmheap to display JVM heap information. See "Modify command" for details. 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.

Verbose JNI

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

Initial heap size

Specifies the initial heap size available to the JVM code, in megabytes.

Increasing the minimum heap size can improve startup. The number of garbage collection occurrences are reduced and a 10% gain in performance is realized.

Increasing the size of the Java heap improves throughput until the heap no longer resides in physical memory, in general. After the heap begins swapping to disk, Java performance suffers drastically.

Data type Integer
Default

For z/OS, the default for the controller is 48, and the default for the servant is 128. These default values apply for both 31-bit and 64-bit configurations.

For the majority of applications these defaults should work quite well.

Maximum heap size

Specifies the maximum heap size available to the JVM code, in megabytes.

Increasing the heap size can improve startup. By increasing heap size, you can reduce the number of garbage collection occurrences with a 10% gain in performance.

Increasing the size of the Java heap usually improves throughput until the heap no longer resides in physical memory. When the heap size exceeds the physical memory, the heap begins swapping to disk which causes Java performance to drastically decrease. Therefore, it is important to set the maximum heap size to a value that allows the heap to be contained within physical memory.

To prevent paging, you should 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 heap size might make performance worse rather than better.

Data type Integer
Default

For the z/OS platform, the default for both 31-bit and 64-bit configurations is 256. Keep the value low enough to avoid paging or swapping-out-memory-to-disk.

For the majority of applications these defaults should work quite well. You can monitor the frequency of garbage collection by enabling Verbose garbage collection field. If garbage collection is occurring too frequently you should increase the maximum size of the JVM heap.

Debug mode

Specifies whether to run the JVM in debug mode. The default is not to 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

Debug arguments

Specifies command-line debug arguments to pass to the JVM code that starts the application server process. You can specify arguments when Debug Mode is enabled.

For WebSphere Application Server Network Deployment configurations, Debug arguments are only required if the Debug Mode property is set to true. If you enable debugging on multiple application servers on the same node, make sure that the servers are using different address arguments, which define the port for debugging. For example, if you enable debugging on two servers and leave the default debug port for each server as address=7777, the servers could fail to start properly.

Data type String
Units Java command-line arguments

Generic JVM arguments

Specifies command line arguments to pass to the Java virtual machine code that starts the application server process.

The following are optional command line arguments that you can enter in the Generic JVM arguments field. If you enter more than one argument, enter a space between each argument.
Important: If the argument says it is for the IBM Developer Kit only, you cannot use the argument with another JVM, such as the Oracle JDK or the HP JDK.
  • -DhotRestartSync: You can use -DhotRestartSync 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, a large numbers of nodes, and run a large numbers of applications.
  • -Xquickstart

    You can use -Xquickstart for initial compilation at a lower optimization level than in default mode. Later, depending on sampling results, you can recompile to the level of the initial compile in default mode. Use -Xquickstart for applications where early moderate speed is more important than long run throughput. In some debug scenarios, test harnesses and short-running tools, you can improve startup time between 15-20%.

  • -Xverify:none

    You can use -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% improvement in startup time. However corrupted or invalid class data is not detected when this option is specified. If corrupt class data is loaded, the Java Virtual Machine (JVM) might behave in an unexpected manner, or the JVM might fail.

    Avoid trouble Avoid trouble:
    • Do not use this option if you are making bytecode modifications, because the JVM might fail if any instrumentation error occurs.
    • If, while this option is in affect, you experience a JVM failure or the JVM behaves in an unexpected manner, remove this option as your first step in debugging your JVM problem.
    gotcha
  • -Xnoclassgc

    You can use -Xnoclassgc to disable class garbage collection. This action leads to more class reuse and slightly improved performance. The trade-off is that you won't be collecting the resources owned by these classes.

    Avoid trouble Avoid trouble: The performance impact of class garbage collection is typically minimal, and turning off class garbage collection in a Java Platform, Enterprise Edition (Java EE) based system, with its heavy use of application class loaders, might effectively create a memory leak of class data, and cause the JVM to throw an Out-of-Memory Exception.gotcha

    You can monitor garbage collection using the verbose:gc configuration setting, which will output class garbage collection statistics. Examining these statistics will help you understand the trade-off between the reclaimed resources and the amount of garbage collection required to reclaim the resources. Class garbage collection is enabled by default.

    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.

  • -Xgcthreads

    You can use several garbage collection threads at one time, also known as parallel garbage collection. When entering this value in the Generic JVM arguments field, also enter the number of processors that are running on your machine.

    Specify -Xgcthreads as follows:

    -Xgcthreads<number of processors>

    Avoid trouble Avoid trouble: Do not add a space between --Xgcthreads and the n value for the number of processors.

    -Xgcthreads5 is an example of specifying -Xgcthreads with 5 processors.

    gotcha

    On a node with n processors, the default number of threads is n.

    You should use parallel garbage collection if your machine has more than one processor. This argument is valid only for the IBM Developer Kit.

  • -Xnocompactgc

    You can use -Xnocompactgc to disable heap compaction, which is the most expensive garbage collection operation. Avoid compaction in the IBM Developer Kit. If you disable heap compaction, you eliminate all associated overhead.

  • -Xgpolicy

    You can use -Xgpolicy to set the garbage collection policy. If the garbage collection policy (gcpolicy) is set to optavgpause, concurrent marking is used to track application threads starting from the stack before the heap becomes full. The garbage collector pauses become uniform and long pauses are not apparent. The trade-off is reduced throughput because threads might have to do extra work. The default, recommended value is optthruput. Enter the value as -Xgcpolicy:[optthruput|optavgpause].  You can use this argument only with the IBM Developer Kit.

  • -XX

    The Oracle-based Java 2 Standard Edition (J2SE) 5 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 short lived objects so that objects in the pool do not live through more then one garbage collection cycle. The size of new generation pool is determined by the NewSize and MaxNewSize parameters.

    Objects that survive the first garbage collection cycle are transferred to another pool. The size of the survivor pool is determined by parameter SurvivorRatio. If garbage collection becomes a bottleneck, you can try customizing the generation pool settings. To monitor garbage collection statistics, use the object statistics in Tivoli Performance Viewer or the verbose:gc configuration setting. Enter the following values:
    -XX:NewSize=lower bound
    -XX:MaxNewSize=upper bound
    -XX:SurvivorRatio=new_ratio_size 
    The default values are:
    • NewSize=2m
    • MaxNewSize=32m
    • SurvivorRatio=32
    Best practice Best practice: However, if you have a JVM with more than 1 GB heap size, you should use the following values:
    • -XX:NewSize=640m
    • -XX:MaxNewSize=640m
    • -XX:SurvivorRatio=16
    bprac

    Alternatively, you could set 50% to 60% of the total heap size to a new generation pool.

  • -Xminf

    You can use -Xminf to specify the minimum free heap size percentage. The heap grows if the free space is below the specified amount. In reset enabled mode, this option specifies the minimum percentage of free space for the middleware and transient heaps. This is a floating point number, 0 through 1. The default is .3 (30%).

  • -server | -client

    Java HotSpot Technology in the Oracle-based Java 2 Standard Edition (J2SE) 5 uses an adaptive JVM containing algorithms for optimizing byte code execution over time. The JVM runs in two modes, -server and -client. If you use the default -client mode, there will be a faster startup time and a smaller memory footprint, but lower extended performance. You can enhance performance by using -server mode if a sufficient amount of time is allowed for the HotSpot JVM to warm up by performing continuous execution of byte code. In most cases, use -server mode, which produces more efficient run-time execution over extended periods. You can monitor the process size and the server startup time to check the difference between -client and -server.

  • -Dcom.ibm.CORBA.RequestTimeout=timeout_interval

    Use -Dcom.ibm.CORBA.RequestTimeout=timeout_interval to specify 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.

    Be careful specifying this property; it has no recommended value. Set it only if your application is experiencing problems with timeouts.

  • -Dcom.ibm.websphere.wlm.unusable.interval=interval

    Use the -Dcom.ibm.websphere.wlm.unusable.interval=interval argument to change the value for the com.ibm.websphere.wlm.unusable.interval property if the workload management state of the client is refreshing too soon or too late. This property specifies the time interval 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. interval is the time in seconds between attempts. 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.

  • -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=

    On z/OS, you can use 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

    The direct byte buffers, that the JVM creates to handle request data, are allocated in the LE heap instead of in the JVM heap. Normally, even if the direct byte buffers are no longer needed, the JVM does not release this native LE storage until the next garbage collection occurs. If the server is handling large requests, LE storage might become exhausted before the JVM runs a garbage collection cycle, causing the server to abnormally terminate (abend). Configuring the JVM with the
    -Dcom.ibm.ws.buffermgmt.impl.WsByteBufferPoolManagerImpl=com.ibm.ws.buffermgmt.impl.ZOSWsByteBufferPoolManagerImpl
    argument prevents these abends from occurring.

    On z/OS, you also need to specify this argument if you are using the zaioFreeInitialBuffers custom property for a TCP channel to indicate that the channel should release the initial read buffers used on new connections as soon as these buffers are no longer needed for the connection.

  • [Fix Pack 31 or later] -Dcom.ibm.server.allow.sigkill=

    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

  • -Xshareclasses:none

    You can use the -Xshareclasses:none argument to disable the share classes option for a process. The share classes option, which is available with Java 2 Standard Edition (J2SE) 5, 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.

    Important:
    • J2EE application classes running in a WebSphere Application Server process are not added to the shared class cache.
  • -XXallowvmshutdown:false

    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

Executable JAR file name

Specifies a full path name for an executable JAR file that the JVM code uses.

Data type String
Units Path name

Disable JIT

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

Operating system name

Specifies JVM settings for a given operating system.

For the Network Deployment product, when the process starts, the process uses the JVM settings for the node as the JVM settings for the operating system.

Data type String



Related tasks
Configuring the JVM
Tuning the application serving environment
Related reference
Custom property collection
Reference topic Reference topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 12:02:36 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-zos&topic=urun_rconfproc_jvm
File name: urun_rconfproc_jvm.html