Re: Serious concurrency problems on fast systems

From:

Tom Anderson <twic@urchin.earth.li>

Newsgroups:

comp.lang.java.programmer

Date:

Tue, 1 Jun 2010 13:08:38 +0100

Message-ID:

<alpine.DEB.1.10.1006011304070.16785@urchin.earth.li>

On Mon, 31 May 2010, Kevin McMurtrie wrote:

I've been assisting in load testing some new high performance servers
running Tomcat 6 and Java 1.6.0_20. It appears that the JVM or Linux is
suspending threads for time-slicing in very unfortunate locations. For
example, a thread might suspend in Hashtable.get(Object) after a call to
getProperty(String) on the system properties. It's a synchronized
global so a few hundred threads might pile up until the lock holder
resumes. Odds are that those hundreds of threads won't finish before
another one stops to time slice again. The performance hit has a ton of
hysteresis so the server doesn't recover until it has a lower load than
before the backlog started.

The brute force fix is of course to eliminate calls to shared
synchronized objects.

Well, yeah.

All of the easy stuff has been done. Some operations aren't well suited
to simple CAS. Bottlenecks that are part of well established Java APIs
are time consuming to fix/avoid.

Sadly true.

Is there JVM or Linux tuning that will change the behavior of thread
time slicing or preemption? I checked the JDK 6 options page but didn't
find anything that appears to be applicable.

I'm not aware of anything. Somewhere out there on the web is a complete
list of the -XX options - see if you can find that and have a read through
it.

tom

--
Yulava? Niob Yam!