Default performance on Sun T5440
jeff.lloyd at algorithmics.com
jeff.lloyd at algorithmics.com
Tue Oct 6 14:02:53 PDT 2009
Hi Jon,
Sorry for the delay - I took a long weekend.
Is it possible you are testing on a faster box than me? Here is mine:
The sparcv9 processor operates at 1164 MHz,
and has a sparcv9 floating point processor.
Jeff
-----Original Message-----
From: hotspot-gc-use-bounces at openjdk.java.net
[mailto:hotspot-gc-use-bounces at openjdk.java.net] On Behalf Of Jon
Masamitsu
Sent: Friday, October 02, 2009 4:33 PM
To: Jeff Lloyd
Cc: hotspot-gc-use at openjdk.java.net
Subject: Re: Default performance on Sun T5440
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
>
>
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
--------------------------------------------------------------------------
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.
--------------------------------------------------------------------------
More information about the hotspot-gc-use
mailing list