<p>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.</p>

<p>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.</p>

<p>Dmytro, what hardware spec was this on, out of curiosity? </p>
<p>Sent from my phone</p>
<div class="gmail_quote">On Sep 7, 2012 11:39 AM, "Azeem Jiva" <<a href="mailto:azeem.jiva@oracle.com">azeem.jiva@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    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.<br>
    <br>
    <br>
    <div>On 09/07/2012 10:35 AM, Vitaly
      Davidovich wrote:<br>
    </div>
    <blockquote type="cite">
      <p>You can have other threads from different processes in the
        system competing though.</p>
      <p>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 ...</p>
      <p>Sent from my phone</p>
      <div class="gmail_quote">On Sep 7, 2012 11:21 AM, "Azeem Jiva"
        <<a href="mailto:azeem.jiva@oracle.com" target="_blank">azeem.jiva@oracle.com</a>>
        wrote:<br type="attribution">
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div bgcolor="#FFFFFF" text="#000000"> 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. <br>
            <br>
             <br>
            <div>On 09/07/2012 10:17 AM, Dmytro Sheyko wrote:<br>
            </div>
            <blockquote type="cite">
              <div dir="ltr"> Hi,<br>
                <br>
                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):<br>
                <br>
                [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]<br>
                <br>
                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.<br>
                <br>
                If we could raise priority of Parallel GC threads, other
                application would have less impact on GC duration.<br>
                <br>
                What do you think?<br>
                <br>
                Thanks,<br>
                Dmytro </div>
            </blockquote>
            <br>
            <pre cols="72">-- 
Azeem Jiva
@javawithjiva</pre>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
    <pre cols="72">-- 
Azeem Jiva
@javawithjiva</pre>
  </div>

</blockquote></div>