Default performance on Sun T5440

Fri Oct 2 13:32:36 PDT 2009

Jeff,

This is what I see running one of our benchmarks with a
1g heap on a T5440.

UseSerialGC

81.908: [GC 81.908: [DefNew: 279616K->34943K(314560K), 1.6078835 secs]
464333K->241833K(1013632K), 1.6080676 secs] [Times: user=1.61 sys=0.00,
real=1.61 secs]

UseParNewGC with default number of GC threads (85).  My appologies but I had
the wrong fraction in my earlier mail.  Not 3/16 but 5/16.  Default
number of GC
threads is approximately number of strands * 5/16.

49.001: [GC 49.001: [ParNew: 314558K->34942K(314560K), 0.1807405 secs]
601002K->350442K(1013632K), 0.1809190 secs] [Times: user=14.67 sys=0.02,
real=0.18 secs]

UseParNewGC with 8 GC threads

51.140: [GC 51.141: [ParNew: 279616K->34943K(314560K), 0.3261322 secs]
464428K->242091K(1013632K), 0.3262756 secs] [Times: user=2.60 sys=0.00,
real=0.33 secs]

I arbitrarily took the last minor collection in each run.

Yes, between 85 GC threads and 8 GC threads we're doing lots more work
(user time)
for not that much gain in GC pause (less than a factor of two).   We're
addressing that
problem with CR 6593758 which will be smarter about the number of GC threads
(use factors such as heap size and Java threads to figure out a better
number of GC
threads).

But I don't see the egregious increase in pause times that you're seeing.

18.8885468 (default number of GC threads) secs vs. 0.1646787 (with 8 GC threads)

So something more is in play.

Jon

Jon Masamitsu wrote On 10/02/09 12:28,:

>Jeff,
>
>When I can get access to a T5440 I'll do some experiments.
>Do you have a benchmark you can give us?
>
>Jon
>
>jeff.lloyd at algorithmics.com wrote On 10/02/09 11:37,:
>
>  
>
>>Hi Jon,
>>
>>I'm using 1.6.0_16.  I can solve it by reducing the number of parallel
>>threads for ParNew or using serial new collection - that's ok.  
>>
>>I just wanted to raise this as a usability issue because I'm a developer
>>and this issue came to me from the field.  I'm concerned that few people
>>in the field understand java/gc enough to fix or even recognize such an
>>issue.  And this is the default jvm behaviour on the new multithreaded
>>servers (though the default is pure parallel gc instead of cms OG -
>>probably the same problem).
>>
>>So, I don't have a problem right now, but I may have more in the future
>>because our app is supported on many platforms and now the default
>>number of gc threads won't work well for clients running the Sun JVM on
>>particular Sun servers.  Maybe 3/16 is too high?
>>
>>Jeff
>>
>>-----Original Message-----
>>From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM] 
>>Sent: Friday, October 02, 2009 2:14 PM
>>To: Jeff Lloyd
>>Cc: hotspot-gc-use at openjdk.java.net
>>Subject: Re: Default performance on Sun T5440
>>
>>Jeff,
>>
>>This might be something different.  First what jdk are you using?
>>What's you command line?  If you are using CMS, can you
>>try a run with -XX:-UseParNewGC?  If not using CMS, can
>>you try -XX:+UseSerialGC (assuming you're using jdk5 or
>>later).
>>
>>Jon
>>
>>jeff.lloyd at algorithmics.com wrote On 10/02/09 10:56,:
>>
>> 
>>
>>    
>>
>>>Hi John,
>>>
>>>Thanks for responding.  However I just want to show you a simple gc
>>>without manually setting the number of gc cpus:
>>>
>>>178.427: [GC 178.427: [ParNew: 471872K->52416K(471872K), 18.8885468
>>>secs] 1054705K->756342K(12530496K), 18.8895357 secs] [Times:
>>>   
>>>
>>>      
>>>
>>user=740.49
>> 
>>
>>    
>>
>>>sys=15.54, real=18.89 secs]
>>>
>>>Compared to a similar gc when I set the max parallel cpus to 8:
>>>
>>>170.531: [GC 170.532: [ParNew: 118014K->13056K(118016K), 0.1646787
>>>   
>>>
>>>      
>>>
>>secs]
>> 
>>
>>    
>>
>>>863713K->771012K(12569856K), 0.1651373 secs] [Times: user=0.76
>>>   
>>>
>>>      
>>>
>>sys=0.05,
>> 
>>
>>    
>>
>>>real=0.17 secs]
>>>
>>>I apologize it isn't totally apples-to-apples because I reduced the YG
>>>   
>>>
>>>      
>>>
>>>from 512M to 128M, but look at the difference in "user" time.  After
>> 
>>
>>    
>>
>>>5-10 minutes of uptime my application was reporting 135 minutes of cpu
>>>time with the default settings.
>>>
>>>I'm not sure if this is helpful to you or the appropriate place to
>>>provide feedback, but this is what people are going to be seeing if
>>>   
>>>
>>>      
>>>
>>they
>> 
>>
>>    
>>
>>>don't understand gc details.
>>>
>>>Jeff
>>>
>>>-----Original Message-----
>>>From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM] 
>>>Sent: Friday, October 02, 2009 1:40 PM
>>>To: Jon Masamitsu
>>>Cc: Jeff Lloyd; hotspot-gc-use at openjdk.java.net
>>>Subject: Re: Default performance on Sun T5440
>>>
>>>Jon Masamitsu wrote On 10/02/09 10:19,:
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>Jeff,
>>>>
>>>>The default number of GC threads was changed to be fewer in
>>>>jdk6u14 (same change in jdk7). I'm guessing you're using
>>>>an older jdk? The number of GC threads depends on the
>>>>number of cores on the platform. I think on the T5440 the
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>^^^^^^^^^^^^  cores should be strands
>>>
>>>
>>>
>>>   
>>>
>>>      
>>>
>>>>number will be about 3/16 * 256 or 48.
>>>>
>>>>
>>>>  
>>>>
>>>>     
>>>>
>>>>        
>>>>
>>>This is still correct.
>>>
>>>
>>>
>>>-----------------------------------------------------------------------
>>>   
>>>
>>>      
>>>
>>---
>> 
>>
>>    
>>
>>>This email and any files transmitted with it are confidential and
>>>   
>>>
>>>      
>>>
>>proprietary to Algorithmics Incorporated and its affiliates
>>("Algorithmics"). If received in error, use is prohibited. Please
>>destroy, and notify sender. Sender does not waive confidentiality or
>>privilege. Internet communications cannot be guaranteed to be timely,
>>secure, error or virus-free. Algorithmics does not accept liability for
>>any errors or omissions. Any commitment intended to bind Algorithmics
>>must be reduced to writing and signed by an authorized signatory.
>> 
>>
>>    
>>
>>>-----------------------------------------------------------------------
>>>   
>>>
>>>      
>>>
>>---
>> 
>>
>>    
>>
>>>   
>>>
>>>      
>>>
>>
>>--------------------------------------------------------------------------
>>This email and any files transmitted with it are confidential and proprietary to Algorithmics Incorporated and its affiliates ("Algorithmics"). If received in error, use is prohibited. Please destroy, and notify sender. Sender does not waive confidentiality or privilege. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. Algorithmics does not accept liability for any errors or omissions. Any commitment intended to bind Algorithmics must be reduced to writing and signed by an authorized signatory.
>>--------------------------------------------------------------------------
>> 
>>
>>    
>>
>
>_______________________________________________
>hotspot-gc-use mailing list
>hotspot-gc-use at openjdk.java.net
>http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>  
>