ParallelGCThreads
Victor Cheung
VictorC at ganz.com
Fri Dec 12 13:18:08 PST 2008
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
>>
>>
>>
>>
>
>
>
>
More information about the hotspot-gc-use
mailing list