WebSphere eXtreme Scale Administration Guide > Plan application deployment > Tune performance
JVM tuning for WebSphere eXtreme Scale
In most cases, WebSphere eXtreme Scale requires little or no special JVM settings. If you have a large amount of objects that are being stored in WebSphere eXtreme Scale, adjust the heap size to an appropriate level to avoid running out of memory.
Platforms
Performance testing occurred primarily on AIX (32 way), Linux (4 way), and Windows (8 way) boxes. With high-end AIX boxes, heavily multi-threaded scenarios can be pushed, and contention points can be identified and fixed.
Object Request Broker (ORB) requirements
The IBM SDK includes an IBM ORB implementation that has been tested with WebSphere Application Server and WebSphere eXtreme Scale.
To ease the support process, use an IBM-provided JVM. Other JVM implementations use a different ORB. The IBM ORB is only supplied out of the box with IBM-provided Java virtual machines. WebSphere eXtreme Scale requires a working ORB to operate. You can use WebSphere eXtreme Scale with third party ORBs, but if a problem in the ORB is identified, contact the ORB vendor for support. The IBM ORB implementation is compatible with third partyJava virtual machines and can be substituted if needed.
Garbage collection
WebSphere eXtreme Scale creates temporary objects that are associated with each transaction, such as request and response, and log sequence. Because these objects affect garbage collection efficiency, tuning garbage collection is critical.
For the IBM virtual machine for Java, use the optavgpause collector for high update rate scenarios (100% of transactions modify entries). The gencon collector works much better than the optavgpause collector for scenarios where data is updated relatively infrequently (10% of the time or less). Experiment with both collectors to see what works best in the scenario. If you see a performance problem, then run with verbose garbage collection turned on to check the percentage of the time that is being spent collecting garbage. Scenarios have occurred where 80% of the time is spent in garbage collection until tuning fixed the problem.
For more information about configuring garbage collection, see Tune the IBM virtual machine for Java.
JVM performance
WebSphere eXtreme Scale can run on different versions of Java 2 Platform, Standard Edition (J2SE). WebSphere eXtreme Scale v6.1 supports J2SE v1.4.2 and above. For improved developer productivity and performance, use J2SE 5 or later to take advantage of annotations and improved garbage collection. WebSphere eXtreme Scale works on 32-bit or 64-bit Java virtual machines.
WebSphere eXtreme Scale is tested with a subset of the available virtual machines, however, the supported list is not exclusive. You can run WebSphere eXtreme Scale on any v1.4.2 or above, but if a problem on the JVM is identified, contact the JVM vendor for support. If possible, use the JVM from the WebSphere runtime on any platform that WebSphere Application Server supports.
For most of the scenarios in which WebSphere eXtreme Scale is used, Java Platform Standard Edition 6 of the JVM performs better than Edition 5 or 1.4. Java 2 Platform, Standard Edition v1.4 performs poorly especially for scenarios that use the gencon collector. Java Platform Standard Edition 5 performs well, but Java Platform, Standard Edition 6 performs better.
Large heaps
When the application needs to manage a large amount of data for each partition, then garbage collection might be a factor. A read mostly scenario performs well even with very large heaps (20 GB or more) if a generational collector is used. However, after the tenure heap fills, a pause proportional to the live heap size and the number of processors on the box occurs. This pause can be large on smaller boxes with large heaps.
WebSphere eXtreme Scale supports WebSphere Real Time Java. With WebSphere Real Time Java, the transaction processing response for WebSphere eXtreme Scale is more consistent and predictable, and the impact of garbage collection and thread scheduling is greatly minimized. The impact is reduced to the degree that the standard deviation of response time is less than 10% of regular Java.
See Use WebSphere Real Time for more information.
Thread count
The thread count depends on a few factors. A limit exists for how many threads a single shard can manage. A shard is an instance of a partition, and can be a primary or a replica. With more shards for each JVM, we will have more threads with each additional shard providing more concurrent paths to the data. Each shard is as concurrent as possible although there is a limit to the concurrency.
Parent topic
Tune performance