What is a good ratio of Java threads to CPUs on Solaris?

Question

I have a Java application that has a fixed thread pool of fifteen, the machine, Solaris 10 SPARC, has sixteen CPUs. Adding the pool has greatly increased performance, but I'm wondering if I have too many threads in the pool. Would performance be better with less threads or does Solaris do a good job of thread scheduling.

Say the pool is heavily using fifteen CPUs, then other application threads demand CPU for various reason, concurrent garbage collection is a good example. Now, five CPUs are shared between the pool and other application threads. Then CPUs one through seven become free, will Solaris move the threads sharing time on the busy CPUs to the free CPUs?

If not, would it be better to keep the pool size smaller, so that there are always free CPUs for other application threads? Compounding the issue, CPU usage is very sporadic in the application.

Answer 1

Generally, if you can establish a 1 to 1 mapping between threads and CPUs, you will get optimal performance. That is assuming that user threads are mapped 1 to 1 with kernel threads. If I recall correctly, Solaris allows multiple kernel threads as well as user threads, so you should be ok in this respect. You will run into bottlenecks when more than one thread is using the same CPU.

As always, the best advice to your question about reducing thread pool size is: "Try and benchmark it." (but I suspect more will be better in this case.)

As for your question about other applications being run, Solaris will use a CPU to alternate between your thread pool and the other application. If a CPU becomes free though, Solaris will move some threads to the free CPU.

EDIT: Here is a link from Sun about how the Solaris and Java thread models interact.

Answer 2

It's generally fine to have a few more threads than CPUs, this can actually help overall throughput.

The reason for this is that several threads may be blocked on IO or sleeping at any given time. So having a few more threads ready to execute never hurts.

Answer 3

If you are doing only cpu intensive tasks (no IO) N+1 threads (where N is the number of cores) will give you the optimum processor utilization.
+1 because you can have a page fault, a therad can be paused to any reason or a small wait time during synchronization.

For Threads doing IO this is not really easy, you have to test the best size.
The book Java concurrency in practice suggests this algorithm as starting point:

N = number of CPUs
U = target CPU utilization (0 <= U <= 1)
W/C = ration of wait time to cpu time (measured through profiling)

threads = N * U * (1 + W/C)

IBM uses the same algorithm in their article Java theory and practice: Thread pools and work queues, with a fixed U=1. The N+1 fact can be read too in the IBM article, to provide origins for both theses.