Administration guide > Tune and performance

JVM tuning for WebSphere eXtreme Scale

JVM tuning can yield a significant improvement in the deployment of WXS.

In most cases, WXS requires little or no special JVM settings. If you have a large amount of objects that are being stored in WXS, adjust the heap size to an appropriate level to avoid running out of memory.


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 WAS and WXS.

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 JVMs. WXS requires a working ORB to operate. Use WXS 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 partyJVMs and can be substituted if needed.

Garbage collection

WXS 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

Use J2SE 5 or later to take advantage of annotations and improved garbage collection. WXS works on 32-bit or 64-bit JVMs.

Most JVMs will work, but, if possible, use the JVM from the WebSphere runtime on any platform that WAS supports.

For most of the scenarios in which WXS 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.

WXS supports WebSphere Real Time Java. With WebSphere Real Time Java, the transaction processing response for WXS 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 and performance

Related concepts

JVM tuning
Operating systems and network tuning
Plan for network ports
ORB properties and file descriptor settings
Use WebSphere Real Time

Related tasks

Configure failover detection
Tune the dynamic cache provider
Tune the cache sizing agent for accurate memory consumption estimates

Related reference

Operational checklist