Parallel GC thread priority

[Vitaly Davidovich]

I see you're on windows, but on Linux I'm almost certain that time spent
waiting for i/o does not count in sys time (it's purely CPU time).  I
suspect, though, that windows does similar accounting but I'm not sure.

Sent from my phone
On Sep 7, 2012 12:31 PM, "Dmytro Sheyko" <dmytro_sheyko at hotmail.com> wrote:

>  Hi,
>
> I can provide following info only:
> ===
> System:
>  Microsoft Windows Server 2003 R2
>  Standard x64 Edition
>  Service Pack 2
> Computer:
>  Intel(R) Xeon(R) CPU E5-2640
>  2.50 GHz, 12.0 GB of RAM
> ===
> JConsole output:
>
> Operating System:       Windows 2003 5.2
> Architecture:           amd64
> Number of processors:   4
>
> Total physical memory:  12,582,100 kbytes
> Free physical memory:    6,184,012 kbytes
> Total swap space:       14,137,188 kbytes
> Free swap space:        11,189,520 kbytes
> ===
> But at time that this long GC pause happened it was 8 GB of RAM. And I
> don't know how much memory was used at that time.
>
> Please note that it's continuous integration server. Some build tasks are
> executed on the same machine. The pause happened on web server, which
> serves UI.
>
> BTW, isn't swapping counted as sys/kernel time?
>
> Thanks,
> Dmytro
>
>
> ------------------------------
> Date: Fri, 7 Sep 2012 11:45:34 -0400
> Subject: Re: Parallel GC thread priority
> From: vitalyd at gmail.com
> To: azeem.jiva at oracle.com
> CC: dmytro_sheyko at hotmail.com; hotspot-gc-dev at openjdk.java.net
>
> Whether it helps or not would depend on what priority the other threads
> are running at.  If the server had several jvms running at the same time
> and they all start a par new collection at about the same time, then yeah
> it won't help if priority is boosted - at that point, the machine is simply
> oversubscribed.
> In Dmytro's case, the wall time is so out of whack with CPU time that I
> wonder if it wasn't swapping that mostly contributed to this.  For such a
> relatively small heap, I can't imagine how much other stuff would have to
> run to inflate the time so much.
> Dmytro, what hardware spec was this on, out of curiosity?
> Sent from my phone
> On Sep 7, 2012 11:39 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  I had not thought about other processes, which is a possibility.
> Although raising the priority of the GC threads won't help which I believe
> what Dmytro was suggestion.
>
>
> On 09/07/2012 10:35 AM, Vitaly Davidovich wrote:
>
> You can have other threads from different processes in the system
> competing though.
> However, such a large wall time vs CPU time can also be caused by heavy
> swapping on a slow disk.  The heap there doesn't look all that big though
> ...
> Sent from my phone
> On Sep 7, 2012 11:21 AM, "Azeem Jiva" <azeem.jiva at oracle.com> wrote:
>
>  The Parallel collector is a stop-the-world collector.  The Java threads
> are suspended until the GC finishes.  I think your survivor spaces maybe
> mis-configured, and that's why you're seeing such large GC times.
>
>
> On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:
>
>  Hi,
>
> I can see that Parallel GC works on threads with NormPriority, while CMS
> and G1 threads run with NearMaxPriority. This probably not an issue if java
> application works alone, but some time ago I observed GC log like this (it
> was Jenkins CI on Windows):
>
> [Full GC [PSYoungGen: 10352K->0K(171904K)] [PSOldGen:
> 403417K->114637K(415872K)] 413769K->114637K(587776K) [PSPermGen:
> 76315K->76315K(83968K)], 30.2595731 secs] [Times: user=0.77 sys=0.41,
> real=30.26 secs]
>
> Despite cpu time for GC was just 1.18 sec (= 0.77 + 0.41), the real time
> was 30.26 sec! It seems to me that the system was busy that time and GC
> threads was starving.
>
> If we could raise priority of Parallel GC threads, other application would
> have less impact on GC duration.
>
> What do you think?
>
> Thanks,
> Dmytro
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
> --
> Azeem Jiva
> @javawithjiva
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20120907/78ac7c9e/attachment.htm>