Sakai 2.2 developer JVM tuning

For developers who are programming for Sakai 2.2 we recommend JVM options (JAVA_OPTS) as specified below.
WARNING: These settings are not meant for servers and should not be used for production Sakai servers. A server guide will be written and linked to from here in the future.

Leaving the heap values at the default is not a good idea because they are totally inadequate for Sakai. It is pretty popular to set the minimum and maximum heap sizes to the same number because this keeps the VM from doing any resizes for the heap. It basically short circuits the resizing portion of the VM garbage collector which can be good or bad depending on your perspective. Probably not a bad idea on a server but on a development machine it could help save a lot of ram for things like eclipse and email if you set the minimum heap size to something like half of the maximum. This is especially true considering that you are likely to be the only user on your instance of Sakai. The old space never went over 120m during my testing. It was actually far more critical to have a large new space than old space (in a server environment this would probably not be the case). That said, if you have enough ram, you are better off with Xms=512 and NewSize=256.

If this is tuned wrong then the garbage collector has to do a major collection of the young and old generations which is bad news. Using the NewSize params let's us hard specify the minimum amount of space to use for the young generation. A good size is probably 1/4 to 1/3 of the minimum heap size. You don't want this to ever get to or pass half of the total heap size. The eden size never exceeded 120m during my testing so 192 should work well (note that 120 would not work well at all, 160 is about the lowest you want to use). 256 is better but for those with only a gig of ram or less 192 will work just fine.
- graphical depiction of the memory space from Sun GC guide

This doesn't affect the garbage collector performance but it helps with Sakai because of all of the classes that are loaded into memory. On startup with 2.2 you are going to see around 70m of classes loaded into the permanent space, if you set this lower than 70 you will slowdown your startup for sure. I never exceeded 100 during my testing though so over 100 is probably overkill. On the other hand, Sakai makes use of a LOT of dynamic classes so I would put the max at 160.

Complete JAVA_OPTS:

-server -Xms384m -Xmx768m -XX:NewSize=192m -XX:MaxNewSize=384m 
-XX:PermSize=96m -XX:MaxPermSize=160m

(you can add in the garbage collection stuff if you want, but if you are not tuning your JVM, you should probably leave them out: -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps)

All these settings are working pretty well for me when I run Sakai 2.2 (without OSP). Using these I don't get any "out of memory" warnings and Sakai will startup in about 110 seconds the first time (after a fresh tomcat), after the first time it will start in about 70 seconds. Once I login, Tests and Quizzes takes about 3 seconds to startup the first time, most everything else comes up almost instantly. I was able to login, load every tool and logout without a single full garbage collection. There were more young collections that I would have liked but it should not be too noticeable. The key is that there were no memory issues and no full garbage collections. Overall time for garbage collection during my testing was around .8 seconds.

While we are on the subject, here are some good MAVEN_OPTS:

-Xms128m -Xmx512m -XX:PermSize=64m

By default the permanent space is too small for maven to do the full sakai 2.2 build without expanding it many times. Also, the heap is too small (though 512 is probably overkill, 384 would work fine). With these settings you will see 0 garbage collections throughout the build, the young generation will stay under 40m and the old under 256m.

Questions and Answers

• Why are you not using -XX:+UseConcMarkSweepGC -XX:+UseParNewGC? I heard those improve performance.
  They do, if you have 2+ processors. The real performance improvement comes in at 3 or more processors. Since most development machines only have 1 processor, the default collector works just fine and is actually faster than the parallel collectors.

These links are helpful if you are researching JVM tuning: http://java.sun.com/docs/hotspot/PerformanceFAQ.html http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html http://java.sun.com/developer/technicalArticles/Programming/turbo/ http://java.sun.com/j2se/1.5.0/docs/tooldocs/index.html#manage