Java – Tuning OpenVZ Containers to work better with Java

While I haven't run any JRuby apps on Tomcat, I have run ColdFusion apps on varied J2EE app servers, and I also have had similar issues.

In these FAQs, you'll see that SOracle says that on 32-bit Windows, you'll be limited to a max heap size of 1.4 to 1.6 GB. I never was able to get it stable that high, and I suspect you're running a similar configuration.

My guess is that your requests are taking a long time to run b/c with a heap size that high, the JVM has allocated more physical memory than Windows had to give, and thus Windows spends a lot of time swapping pages in and out of memory to disk so it can provide the required amount of memory to the JVM.

My recommendation, although counter-intuitive, would be that you actually lower the max heap size to somewhere around 1.2 GB. You can raise the min size as well, if you notice that there are slow-downs in the app's request processing while the JVM has to ask Windows for more memory to increase the size of its heap as it fills with uncollected objects.

Doublecheck if your script translated the raw beancounters correctly. according to this you only have 256 megs of RAM, not 4 gigs as your admin tells you.

concentrate only on 2 beans:

• privvmpages - maximum amount of memory your container can allocate (reserve)
• oomguarpages - guaranteed amount of memory your container will get to actually use. In case of tight memory situation on the host everything using over that amount will probably be killed.

Java is notorious for allocating gobs of memory and then never using them, counting on the OS to overcommit. In my experience you need at least a gig of privvmpages to run JVM reliably, although only couple of dozen megs will be used.

After couple of months experimenting and trying to contain privvmpages in VEs running Java, I have personally given up, I just set the barrier to the max and tweak the oomguarpages appropriately and hope for the best ;)