ParallelGCThreads
Jon Masamitsu
Jon.Masamitsu at Sun.COM
Fri Dec 12 21:52:29 UTC 2008
Victor,
The -Xmx should not be set based on the number of cpu's on the
machine. You still only have 1 JVM and 1 heap so the -Xmx should
be set to use the available memory. So for a 32GB machine something
like -Xmx30g would be good. Now having said that, if you have other
processes running on the machine, you might want to reduce that.
With 30g setting you're leaving memory for the OS to use. If you have
2 JVM's running, I would use something like -Xmx15g for each. You
don't want any swapping and if you have 2 JVM's each using
-Xmx30g, you will likely get swapping. Swapping will make your
GC times horrendous.
Jon
Victor Cheung wrote On 12/12/08 13:18,:
>Hi Jon,
>
>Unfortunately, no. That's a production log and the GC logging options are not (and likely will not) be set on production.
>
>Regarding the memory per CPU, what I meant was (and ignoring how much memory or live data the web application actually needs for the moment... just from a pure "allocate what you can" perspective), given that my server has 8 CPUs and 32GB of memory, in the JBoss start up script, is it wrong to set for example, -Xmx=28G? Because in the regular scenario, we would have 1 CPU in our machine and we would set -Xmx based on the total memory installed whatever that may be. But for a multi-CPU machine, do we need to be mindful of the fact that there's 8 CPUs servicing the JVM and therefore the -Xmx should be set on a "per CPU" basis (i.e. to split the total amount of memory installed on the machine by the number of CPUs installed on the machine -- and therefore set something like -Xmx=3G)?
>
>I hope this is clearer... (it entirely possible my question is irrelevant/dumb/etc.. but I'm not leaving any stone unturned!)
>
>victor
>
>
>-----Original Message-----
>From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM]
>Sent: Friday, December 12, 2008 3:00 PM
>To: Victor Cheung
>Cc: hotspot-gc-use at openjdk.java.net
>Subject: Re: ParallelGCThreads
>
>Victor,
>
>Does that file have a GC log in it? I didn't see that info
>and I meant to ask for a GC log.
>
>In general the maximum size of the heap that you need
>depends on the amount of live data you have. In the
>sense that more cpu's means more application threads
>creating more objects, yes, more cpu's means you
>need a larger heap. Beyond that I don't have
>any general suggestion of how much memory per
>cpu.
>
>Jon
>
>Victor Cheung wrote On 12/12/08 10:57,:
>
>
>
>>Hi Jon,
>>
>>I've attached our log file for you. Also, do you know if the Xmx setting should be based on a memory per CPU calculation? (So, 8CPU 32GB should set at most Xmx=4G)
>>
>>Thanks,
>>Victor
>>
>>
>>-----Original Message-----
>>From: Jon.Masamitsu at Sun.COM [mailto:Jon.Masamitsu at Sun.COM]
>>Sent: Friday, December 12, 2008 12:55 PM
>>To: Victor Cheung
>>Cc: hotspot-gc-use at openjdk.java.net
>>Subject: Re: ParallelGCThreads
>>
>>If you have 2 VM's running, yes, it is a good idea to specify the
>>number of GC threads. 4 per VM is a safe number but might
>>not be optimum depending on your primary requirements.
>>If you want to maximize throughput (perhaps at the cost
>>of some longer pauses), you could try a larger number (6?).
>>If you want more regular GC pauses, stick with 4.
>>
>>I don't think this is the cause of
>>"OutOfMemoryException GC overhead limit exceeded"
>>but could be wrong.
>>
>>Can you send a log with this error?
>>
>>Victor Cheung wrote On 12/12/08 08:40,:
>>
>>
>>
>>
>>
>>>I don't know why this didn't hit me until now. But our server is
>>>running 2 JBoss services like so:
>>>
>>>service jboss-app1 start
>>>
>>>service jboss-app2 start
>>>
>>>Therefore I'm assuming that's 2 JVMs running (I will confirm this soon
>>>with the admin), and since the young generation collector is defaulted
>>>to use the -XX:+UseParallelGC, I should set the
>>>-XX:ParallelGCThreads=4 for both of the applications given that they
>>>are both running on the same 8CPU machine. Is this correct?
>>>
>>>This thread
>>>(http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2008-April/000235.html)
>>>says that:
>>>
>>>Having many more net GC worker threads than cores will often increase
>>>
>>>GC termination times because workers with work to do will not get time on
>>>
>>>a CPU. This can appear as either longer (or more erratic) GC pauses,
>>>
>>>that might translate into erratic application-level response times.
>>>
>>>Could this be a possible cause of "OutOfMemoryException GC overhead
>>>limit exceeded" errors?
>>>
>>>victor
>>>
>>>------------------------------------------------------------------------
>>>
>>>_______________________________________________
>>>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
More information about the hotspot-gc-dev
mailing list