[concurrency-interest] multi-core cpus & java
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
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.
More information about the Concurrency-interest