Program guide > Performance considerations
JVM tuning
You must take into account several specific aspects of Java™ virtual machine (JVM) tuning for WebSphere eXtreme Scale best performance.
The recommendation is 1 to 2Gb heaps with a JVM per 4 cores. The heap sizes depend on the nature of the objects being stored in the servers, discussed later in this document.
Heap size and garbage collection recommendations
The optimum heap size number depends on three factors:
- Number of live objects in the heap.
- Complexity of live objects in the heap.
- Number of available cores for the JVM.
For example, an application storing 10K byte arrays can run a much larger heap than an application using complex graphs of POJOs.
All modern JVMs today use parallel garbage collection algorithms, which means that using more cores can reduce pauses in garbage collection. So, 8-core boxes will be collected faster than a box with 4 cores.
Real memory usage versus heap specification
A 1Gb heap JVM uses approximately 1.3Gb of real memory. In our lab, we have been unable to run ten 1Gb JVMs on a box with 16Gb of RAM. Once the JVM heaps filled up to 800 plus MB, the box started paging.
Garbage collection
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.
JVM performance
WebSphere eXtreme Scale can run on different versions of Java 2 Platform, Standard Edition (J2SE). ObjectGrid v6.1 supports J2SE Version 1.4.2 and later. For improved developer productivity and performance, use J2SE 5 or later to take advantage of annotations and improved garbage collection. ObjectGrid works on 32-bit or 64-bit JVMs.
ObjectGrid v6.0.2 clients can attach to an ObjectGrid Version 6.1 data grid. Use ObjectGrid v6.1 clients for J2SE Version 1.4.2 or better clients. The only reason to use an ObjectGrid Version 6.0.2 client is for J2SE v1.3 support.
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 WAS supports.
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.
orb.properties tuning
The recommendation is to use the following orb.properties file for production. In our lab, we have used this file on data grids of up to 1500 JVMs. The orb.properties file is in the lib folder of the JRE being used.
# IBM JDK properties for ORB org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton # WS Interceptors org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer # WS ORB & Plugins properties com.ibm.CORBA.ForceTunnel=never com.ibm.CORBA.RequestTimeout=10 com.ibm.CORBA.ConnectTimeout=10 # Needed when lots of JVMs connect to the catalog at the same time com.ibm.CORBA.ServerSocketQueueDepth=2048 # Clients and the catalog server can have sockets open to all JVMs com.ibm.CORBA.MaxOpenConnections=1016 # Thread Pool for handling incoming requests, 200 threads here com.ibm.CORBA.ThreadPool.IsGrowable=false com.ibm.CORBA.ThreadPool.MaximumSize=200 com.ibm.CORBA.ThreadPool.MinimumSize=200 com.ibm.CORBA.ThreadPool.InactivityTimeout=180000 # No splitting up large requests/responses in to smaller chunks com.ibm.CORBA.FragmentSize=0
Thread count
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 even so, a limit exists.
Parent topic:
Performance considerations for application developers
Related concepts
Plug-in evictor performance best practices
Locking performance best practices
ObjectTransformer interface best practices