JVM Performance Tuning

The process of tuning Sakai is very similar to tuning other J2EE applications, though Sakai generally requires a number of particular tunings to run and perform well.

Note: many of the example settings are Sun JVM specific (as it is far and away the most popular JVM used in the Sakai community) – though most JVM implementations have similar settings/concepts.

Server VM

Sun JVMs actually have 2 implementations, a client and server. The server implementation takes somewhat longer to start up, and consumes additional memory, but generally performs better. As of JDK 1.5? most "server-class" machines (multiple CPU, large amount of RAM) will generally automatically choose the server VM, though you can explicitly select it by using:

32-bit vs 64-bit JVMs

32 bit OS's (by nature of having only 32 bits to address memory) can only provide your Java process with 4 GB of virtual address space. In reality this may result in a maximum JVM allocation as small as 2 GB, (on some systems the other 2 GB is reserved for the OS) Further, this 2 GB is allocated between various things (e.g. Permgen, Headers, Heap), so the heap may get only about 1.6 GB.

A number of the objects allocated during normal Sakai operations may be quite large – as a result, a 32-bit JVM may not be capable of addressing enough memory to support a large number of concurrent users.

Permgen Allocation

The permanent generation is where Java allocates class definitions among other things – and is often not subject to garbage collection. Due to the large number of components and generated classes used in Sakai, the default value (64MB on most systems) is often insufficient.

Depending on the mix of tools and components you have installed, the maximum value for this space should probably be at least 128MB, possibly 256MB or higher. e.g.

You may also wish to fix the allocation of this PermGen space to increase predictability for memory footprint, and reduce the likelyhood of a performance impact from a poorly timed resize operation. e.g.

Heap Sizing

As a server application, to handle many concurrent users you will want to generously allocate RAM. Again depending on workload, institutions have had success with heap sizes ranging from 1.5-13GB in size.

This is another area where you may wish to fix (min & max) size of the memory allocation to gain predictability and prevent resizing.

Memory Allocations

In the generational memory model (used on all major JVMs) you may also see benefits from adjusting the allocation of memory regions (particularly your new, eden, and survivor spaces)

Garbage Collection Strategy/Implementations

Sun JVMs have a number of different garbage collection strategies tuned for particular workflows. While the default settings have gotten better with each generation, your individual workloads may benefit from tuning.

Community members have had success with both ConcurrentMarcSweep and ParallelGC.

or

You can also tune collection in the New generation: see http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

Logging

A key aspect of performance tuning the JVM is having visibility into memory allocations and garbage collection statistics. There are a number of mechanisms for retriving this data:

VerboseGC log:

1. This does add minor performance, and some log-file storage overhead
2. Don't forget to fix the xloggc path

jstat: