[concurrency-interest] multi-core cpus & java

Gregg Wonderly gregg at cytetech.com
Mon Nov 13 09:12:36 EST 2006



Dhanji R. Prasanna wrote:
> 
> On 11/13/06, *David Holmes* <dcholmes at optusnet.com.au 
> <mailto:dcholmes at optusnet.com.au>> wrote:
> 
>      
>     Application tuning on such systems needs to be considered at deploy
>     time as there is no runtime facility in the VM to determine the
>     nature of the underlying processors.
> 
> 
> If the nature of the processor is known at deploytime, what might be 
> some considerations in tuning a multi-threaded app on a jvm? (such as an 
> appserver)

One of the predominate factors in utilizing any computing system is resource 
contention.  Resources which are heavily contendend need to be considered from 
several perspectives.  Memory contention is often implicit in CPU contention, 
but that is a hardware architecture issue.  Network bandwidth contention and 
associated latency go together.  Buffering in the OS comes into play.

My general practice is, at runtime, to start with two threads for any particular 
contended latency related resource.  I add threads only if I'm not realizing the 
needed performance and then use throughput measurement per thread to see if 
adding that thread increased or decreased the throughput of the system overall. 
  I look for increased latency, per thread as an indication that resources are 
now overly contended.

For any N visible processors (multi-core or N-way), I try to use N+1 threads as 
a starting point for CPU bound paths.  If I'm not making the needed throughput, 
I look at the load average to see whether I am CPU bound, or latency bound.  If 
the CPU use is less than 30% or so, I'll add a thread and see whether the load 
average goes up or down.  If the load average is high, I'll decrease the number 
of threads to look for memory/cache thrashing.

If you have java.nio based I/O subsystem use, then more worker threads on the 
backside might be what solves a throughput issue.  But, it might be that you 
really just have an arrival rate that exceeds the memory throughput of your 
hardware.  So, you might need to do some measuring, and look for the hot spots 
using a profiling tool.  Netbeans has one built in.  I like to use the "Your 
Kit" profiler because it lets me have it available in a running JVM. I can 
switch it on, and any moment, get a snapshot of memory and/or CPU and turn it 
off again.  It also supports memory dump on overflow and VM exit.

Gregg Wonderly


More information about the Concurrency-interest mailing list