Search



Recent Entries

Syndicate this site (XML)
Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by
Movable Type 3.17

« Getting IntelliJ 4.52 and 4.5.3 working on Linux AMD64/JDK1.5 | Main | SimonSays: A stretch reminder program to cure those stiff necks »

December 01, 2004

Threads as a metric of the scalability of Java Virtual Machines - by Operating System

The scalability of a JVM depends on: - maximum memory - maximum number of threads - garbage collection - a host of miscellaneous factors. In this survey I look at the maximum number of threads. It shows that Linux is by far the superior Java platform followed distantly by Windows and then Mac OS X. The test is included along with JVM and OS settings so you can confirm the numbers. I focus on threads because it is one of the hardest things to pin down. It is also important because: - it tells you how many threads your app can support - you can predict how long your app can run if it has thread leaks Thread leaks are not as rare as they sound. Sun's JMX Remoting library, which is now standard in JDK1.5 has a slow one, for example.
A Test ==== Download the attached thread-test.jar. Standalone --------- This will tell you what you JVM can do if it is not doing anything else. To run the test standalone: java -jar thread-test.jar or java -cp thread-test.jar com.wotif.jaguar.threading.ThreadManualTest e.g. java -jar thread-test.jar 20000 20000 should exhaust most 32 bit VMs. From your application ------------------ The thread test gets much more interesting when run inside your app. Load your application up so that it is using its memory peak and then get it to call the thread test. Call the main method in com.wotif.jaguar.threading.ThreadManualTest with 20000 as an argument. Don't be surprised if you can only create a few hundred threads! Standalone Test Results By Operating System ============================ Mac OS X -------- 2550 threads. The JVM is not tunable to produce more threads. Multi processor machines have the -XX:+UseTLAB turned on by default. According to the doco 
Enables a thread-local allocation buffer. Using the buffer allows for more scalable allocation for heavily threaded applications, greatly increasing allocation performance. It is on by default on multiprocessor computers and in Mac OS X Server.
It seems to have no effect on my dual cpu PowerMac. There is also a setting -XX:ThreadStackSize=size in KB which changes the thread stack size from the operating system’s default size. Once again this has no effect. Windows XP Professional --------------------- 7200 threads. The JVM -Xss stack size entry permits larger stack sizes than the default 256k, but not smaller ones. Therefore 7200 was the default and maximum. Linux (Redhat 9 or Fedora, 2.4 kernel, NPTL) ------------------------------------- java -cp thread-test.jar com.wotif.jaguar.threading.ThreadManualTest 20000 gives 3042 threads java -Xss100k -cp thread-test.jar com.wotif.jaguar.threading.ThreadManualTest 20000 gives 16359 threads The default stack size in Linux is 512kb, thus the 3042 threads by default. The stack size can be set lower. We run in production with the 100kb settings which works fine. It gives a maximum of 16359 64 bit Linux 2.6 (Fedora Core 2) JDK1.5.0 64 bit ---------------------------------------- java -client -Xss100k -Xms800m -Xmx4000m -jar thread-test.jar 100000. The machine has 4GB of RAM. 32236 threads can be created. The limiting factor is memory, as each thread was set to use 100kb. Analysis By Operating System ================== Mac OS X -------- Mac OS X has a current JVM (1.4.2) which seems to work very well. They do not however include the server hotspot VMs in their offering and do not provide as many tuning features. The smaller number of threads seems to indicate a default stack size of 768kb. It is not clear how Mac OS X would go as a J2EE server platform. Linux Analysis ------------ The JVM for Linux is very tunable as is the OS itself. To produce the maximum number of threads: Use -Xss100k. Increase the user process limit. e.g. ulimit -u 20000 Increase the kernel threads-max setting e.g. echo 20000 > /proc/sys/kernel/threads-max The 64 bit JDK1.5.0 on 64 bit Linux is scalable limited only to memory in the testing I did. Linux is clearly the superior OS :) The Meta Group released a report in February predicting Linux would be the dominant J2EE OS by 2006. Its superior stability and superior scalability and tunability are all reasons why this is happening. Windows ------- Windows performs ok. It would be interesting to find out if it is tunable to run larger numbers of threads. Likely In-Application Results ================= While I was able to get 16359 threads running the thread-test.jar on its own, when I ran it from within a loaded J2EE app I work on, the maximum it could create was about 1100. Together with the application's 300 odd threads this have a total of about 1400. Exceeding Your Application's Maximum Thread Count --------------------------------------------- If you exceed the maximum thread count for your application, the JVM will terminate with an OutOfMemory Exception. Why? Well, when the JVM goes to create more threads, it first sees if it can allocate the memory for them. That's why an exception which should be someting like "CannotCreateAnyMoreThreads" Exception is an OutOfMemory Exception. Predicting the Maximum Number of Threads ------------------------------------- The formula is: available JVM memory / Stack Size. Available memory is total memory less the heap less a list of other things (which seems to be around 500MB). As you app grows and consumes more memory you are able to support fewer threads. Get the thread test here: Download file

Posted by gluck at December 1, 2004 08:00 PM

Comments

It would be mildly interesting to see how the MacOS X test goes on one of their server models (I'm assuming you used a laptop or desktop model). The server models have significantly differently configured kernels, which may well interact with the threading model used by the JVM. However, in general Java on the Mac is aimed at client-side development.

Posted by: Robert Watkins at November 30, 2004 08:58 PM

Solaris was able to run the entire test as well without problems, so Linux can't say it's better than Solaris 9 - based on this test, at least.

Posted by: Joseph Ottinger at December 1, 2004 10:25 PM

Interesting study but I don't see how it has accounted for variations in VM configurations that affect the number of threads that you can launch. You may want to look at defaults for the various platforms and then "normalize" them.

Posted by: Kirk at December 2, 2004 05:34 PM