See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in
with your developerWorks ID, you can leave comments and feedback for the development team.
This page discusses some specific questions about Java virtual machine (JVM) tuning for ObjectGrid.
If you are seeing performance problems, contact IBM support. This page will be updated with additional tuning information as it becomes available.
What was tested?
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.
Which garbage collector is best?
For IBM JVMs, use the avgoptpause collector for high update rate scenarios (100% of transactions modify entries). The gencon collector works much better than the avgoptpause 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 your 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.
Which JVM works best?
Java Platform, Standard Edition 6 is the best JVM. Java 2 Platform, Standard Edition, v 1.4 performs poorly especially for scenarios where the gencon collector makes a difference. Java Platform Standard Edition 5 performs well, but Java Platform, Standard Edition 6 performs better.
Very 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, then 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.
How many threads should be used?
The thread count depends on a few factors. A limit exists for how many threads a single shard can manage. With more shards for each JVM, more threads and more concurrency can exist. Each additional shard provides more concurrent paths to the data. Each shard is as concurrent as possible but never the less, there is still a limit.
© Copyright IBM Corporation 2007,2009. All Rights Reserved.
