Summary: As part of configuring GigaSpaces, you can fine-tune settings that enhance system use of the JVM.
Overview - Tuning Java Virtual MachinesGigaSpaces, being a Java process, requires a Java virtual machine (JVM) to run. As part of configuring GigaSpaces, you can fine-tune settings that enhance system use of the JVM. A JVM provides the runtime execution environment for Java-based applications. GigaSpaces can run on JVMs from different JVM providers. When GigaSpaces starts it writes information about the JVM, including the JVM provider information, into this log file and the standard output. Even though JVM tuning is dependent on the JVM provider, general tuning concepts apply to all JVMs. Garbage CollectorThe garbage collector is the key to effectively managing the JVM memory system, which is the ultimate goal of JVM tuning. Garbage collection is the process of clearing dead objects from the heap, thus releasing that space for new objects. Application ThroughputThe garbage collector is optimized for application throughput. This means that the garbage collector works as effectively as possible, giving as many CPU resources to the Java threads as possible. This may, however, cause non-deterministic pauses when the garbage collector stops all Java threads for garbage collection. The throughput priority should be used when non-deterministic pauses do not impact the application's behavior. Pause TimeThe garbage collector is optimized to limit the length of each garbage collection pause where all Java threads are stopped for garbage collection. This may result in lower application throughput, as the garbage collector uses more CPU resources in total than when running with the throughput priority. The pause time priority should be used when the application depends on an even performance. Why and When to Perform this TaskGigaSpaces, being a Java process, requires a Java virtual machine (JVM) to run. As part of configuring GigaSpaces, you can fine-tune settings that enhance system use of the JVM. A JVM provides the runtime execution environment for Java-based applications. GigaSpaces can run on JVMs from different JVM providers. When GigaSpaces starts it writes information about the JVM, including the JVM provider information, into this log file and the standard output.
Optimize Startup Performance and Runtime PerformanceIn some environments, it is more important to optimize the startup performance of GigaSpaces rather than the runtime performance. In other environments, it is more important to optimize the runtime performance. By default, IBM JVMs are optimized for runtime performance while HotSpot based JVMs are optimized for startup performance. Set Heap SizeGenerally, you may want to set the maximum heap size as high as possible, but not so high that it causes page faults for the application or for some other application on the same computer. Heap sizing is accomplished by using the -Xms (minimum heap size) and -Xmx (maximum heap size) options.
Garbage CollectionThe recommendations in this section are for non-manager VMs only. Garbage collection, while necessary, introduces latency into your system by consuming resources that would otherwise be available to your application. If you are experiencing unacceptably high latencies in application processing, you might be able to improve performance by modifying your VM's garbage collection behavior. Garbage collection tuning options depend on the Java virtual machine you are using. -XX:+UseConcMarkSweepGC -XX:+UseParNewGC For application VMs, if you are not using shared memory and you are using remote method invocation (RMI) Java APIs, you might also be able to reduce latency by disabling explicit calls to the garbage collector. The RMI internals automatically invoke garbage collection every sixty seconds to ensure that objects introduced by RMI activities are cleaned up. Your VM may be able to handle these additional garbage collection needs. If so, your application may run faster with explicit garbage collection disabled. You can try adding the following command-line parameter to your application invocation and test to see if your garbage collector is able to keep up with demand: -XX:+DisableExplicitGC Remote GCThe sun.rmi.dgc.client.gcInterval and sun.rmi.dgc.server.gcInterval properties are set by default to 60000 milliseconds (60 seconds). In some cases this might cause the JVM process to slow down every 60 seconds. To reduce the performance impact of redundant GC cycles, increase the interval to be 10 hours (36000000 milliseconds) both for the space JVM and the client JVM.
UseBiasedLocking JVM OptionThe UseBiasedLocking JVM option impacts GigaSpaces performance when running synchronized replication (and also one-way mode) when used with Solaris 10. Please avoid using this option with clients accessing the space and space servers JVM.
-XX:+UseBiasedLocking enables a technique for improving the performance of uncontended synchronization. An object is "biased" toward the thread which first acquires its monitor via a monitorenter bytecode or synchronized method invocation; subsequent monitor-related operations performed by that thread are relatively much faster on multiprocessor machines. Some applications with significant amounts of uncontended synchronization may attain significant speedups with this flag enabled; some applications with certain patterns of locking may see slowdowns, though attempts have been made to minimize the negative impact. Tuning 64-bit JVMOn 64-bit systems, the call stack for each thread is allocated with 1MB of memory space. Most threads do not use that much space. Using the -XX:ThreadStackSize=256k flag, you can decrease the stack size to 256k to allow more threads. The -Xmn<size> flag lets you manually set the size of the "young generation" memory space for short-lived objects. If your application generates lots of new objects, you might improve GCs dramatically by increasing this value. The "young generation" size should almost never be more than 50% of heap. The -XX:+UseCompressedOops option can improve performance of the 64-bit JRE when the Java object heap is less than 32 gigabytes in size. In this case, HotSpot compresses object references to 32 bits, reducing the amount of data that it must process. Available in Sun JVM since JDK6u14. ReferencesGeneral:
Sun JVM:
IBM JVM: BEA JVM:
Tuning Operating Systems: |
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |