Re: JVM performance on Linux (vs. Solaris/Windows)

["Jeff V. Merkey" <jmerkey@wolfmountaingroup.com>]

Martin J. Bligh wrote:

> K P wrote:
>
>> Sun's recently published SPECjbb_2005 numbers on Linux, Windows and
>> Solaris on their
>> Opteron system, and the Linux result is the lowest of the three by far:
>>
>> Linux: 
>> http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00062.html 
>>
>> Solaris: 
>> http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00063.html 
>>
>> Windows: 
>> http://www.spec.org/jbb2005/results/res2006q1/jbb2005-20060117-00064.html 
>>
>>
>> It's not evident if Sun spent any time analyzing and tuning the Linux
>> result. While the
>> majority of the tuning opportunities for SPECjbb_2005 are likely to be
>> in the JVM itself, I was
>> wondering (given the large spread between the OS's) if there were
>> other typical opportunities
>> to tune the Linux kernel for JVM performance and SPECjbb_2005.
>>
>> There are some other results showing excellent scalability with 
>> SPECjbb_2005 on
>> Linux/Itanium (such as SGI's:
>> http://www.spec.org/jbb2005/results/res2006q2/ ), but it's
>> not clear if there are other opportunities for tuning unique to Linux
>> on Opteron, or Linux
>> in general that should be explored
>>
>> Comments?
>>  
>>
>
> SpecJBB is a really frigging stupid benchmark. It's *much* more affected
> by the stupid crap in Java (like their locking model) than anything in 
> the
> OS.
> Best to find another benchmark, oh and preferably somebody vaguely
> objective to run it ;-)
>
> M.
>
Note they ran the benchmark on an Opteron 285 instead of a Xeon with 16 
GB of memory.    Opteron peformance currently **SUCKS** with 2.6 series 
kernels under any kind of heavy I/O due to their cloning of the ancient 
82489DX architecture for I/O interrupt access and performance.  Looks 
like the test was stakced against Linux from the start.  Should have 
used a Xeon system. 

AMD needs to get their crappy I/O performance up to snuff.  Looking at 
the test parameteres leads me to believe there was a lot of swapping on 
a system with already poor I/O performance.

Jeff