<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Ramki,<br>
    <br>
    Yes, I am agreed with you. 31 is too large and I have removed the
    parameter (using default now). Nevertheless this is not the problem
    as the max used age was always 1.<br>
    <br>
    Since the most (more than 90%) new allocated objects in our
    application live for a long time (>1h) we mostly will have
    premature promotion.<br>
    Is there a way to optimize this?<br>
    <br>
    I have seen most time, when young gc needs much time (> 6 secs)
    there is only one large block in the old gen. If there has been a
    cms-old-gen-collection and there are more than one blocks in the old
    generation it is mostly (not always) much faster (needs less than
    200ms).<br>
    <br>
    Is it possible that premature promotion can not be done parallel if
    there is only one large block in the old gen?<br>
    <br>
    In the past we have had a problem with fragmentation on this server
    but this is gone since we increased memory for it and triggered a
    full gc (compacting) every night, like Tony advised us. With setting
    the initiating occupancy fraction to 80% we have only a few (~10)
    old generation collections (which are very fast) and the heap
    fragmentation is low.<br>
    <br>
    Flo<br>
    <br>
    <br>
    Am 09.01.2012 19:40, schrieb Srinivas Ramakrishna:
    <blockquote
cite="mid:CABzyjy=23c+csJ3ffo5c=2VQeXmuiiZ1z+EyVbfgYV5M2MZcCA@mail.gmail.com"
      type="cite">Haven't looked at any logs, but setting
      MaxTenuringThreshold to 31 can be bad. I'd dial that down to 8,<br>
      or leave it at the default of 15. (Your GC logs which must
      presumably include the tenuring distribution should<br>
      inform you as to a more optimal size to use. As Kirk noted,
      premature promotion can be bad, and so can<br>
      survivor space overflow, which can lead to premature promotion and
      exacerbate fragmentation.)<br>
      <br>
      -- ramki<br>
      <br>
      <div class="gmail_quote">On Mon, Jan 9, 2012 at 3:08 AM, Florian
        Binder <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:java@java4.info">java@java4.info</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Hi everybody,<br>
          <br>
          I am using CMS (with ParNew) gc and have very long (> 6
          seconds) young<br>
          gc pauses.<br>
          As you can see in the log below the old-gen-heap consists of
          one large<br>
          block, the new Size has 256m, it uses 13 worker threads and it
          has to<br>
          copy 27505761 words (~210mb) directly from eden to old gen.<br>
          I have seen that this problem occurs only after about one week
          of<br>
          uptime. Even thought we make a full (compacting) gc every
          night.<br>
          Since real-time > user-time I assume it might be a
          synchronization<br>
          problem. Can this be true?<br>
          <br>
          Do you have any Ideas how I can speed up this gcs?<br>
          <br>
          Please let me know, if you need more informations.<br>
          <br>
          Thank you,<br>
          Flo<br>
          <br>
          <br>
          ##### java -version #####<br>
          java version "1.6.0_29"<br>
          Java(TM) SE Runtime Environment (build 1.6.0_29-b11)<br>
          Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02, mixed mode)<br>
          <br>
          ##### The startup parameters: #####<br>
          -Xms28G -Xmx28G<br>
          -XX:+UseConcMarkSweepGC \<br>
          -XX:CMSMaxAbortablePrecleanTime=10000 \<br>
          -XX:SurvivorRatio=8 \<br>
          -XX:TargetSurvivorRatio=90 \<br>
          -XX:MaxTenuringThreshold=31 \<br>
          -XX:CMSInitiatingOccupancyFraction=80 \<br>
          -XX:NewSize=256M \<br>
          <br>
          -verbose:gc \<br>
          -XX:+PrintFlagsFinal \<br>
          -XX:PrintFLSStatistics=1 \<br>
          -XX:+PrintGCDetails \<br>
          -XX:+PrintGCDateStamps \<br>
          -XX:-TraceClassUnloading \<br>
          -XX:+PrintGCApplicationConcurrentTime \<br>
          -XX:+PrintGCApplicationStoppedTime \<br>
          -XX:+PrintTenuringDistribution \<br>
          -XX:+CMSClassUnloadingEnabled \<br>
          -Dsun.rmi.dgc.server.gcInterval=9223372036854775807 \<br>
          -Dsun.rmi.dgc.client.gcInterval=9223372036854775807 \<br>
          <br>
          -Djava.awt.headless=true<br>
          <br>
          ##### From the out-file (as of +PrintFlagsFinal): #####<br>
          ParallelGCThreads                         = 13<br>
          <br>
          ##### The gc.log-excerpt: #####<br>
          Application time: 20,0617700 seconds<br>
          2011-12-22T12:02:03.289+0100: [GC Before GC:<br>
          Statistics for BinaryTreeDictionary:<br>
          ------------------------------------<br>
          Total Free Space: 1183290963<br>
          Max   Chunk Size: 1183290963<br>
          Number of Blocks: 1<br>
          Av.  Block  Size: 1183290963<br>
          Tree      Height: 1<br>
          Before GC:<br>
          Statistics for BinaryTreeDictionary:<br>
          ------------------------------------<br>
          Total Free Space: 0<br>
          Max   Chunk Size: 0<br>
          Number of Blocks: 0<br>
          Tree      Height: 0<br>
          [ParNew<br>
          Desired survivor size 25480392 bytes, new threshold 1 (max 31)<br>
          - age   1:   28260160 bytes,   28260160 total<br>
          : 249216K->27648K(249216K), 6,1808130 secs]<br>
          20061765K->20056210K(29332480K)After GC:<br>
          Statistics for BinaryTreeDictionary:<br>
          ------------------------------------<br>
          Total Free Space: 1155785202<br>
          Max   Chunk Size: 1155785202<br>
          Number of Blocks: 1<br>
          Av.  Block  Size: 1155785202<br>
          Tree      Height: 1<br>
          After GC:<br>
          Statistics for BinaryTreeDictionary:<br>
          ------------------------------------<br>
          Total Free Space: 0<br>
          Max   Chunk Size: 0<br>
          Number of Blocks: 0<br>
          Tree      Height: 0<br>
          , 6,1809440 secs] [Times: user=3,08 sys=0,51, real=6,18 secs]<br>
          Total time for which application threads were stopped:
          6,1818730 seconds<br>
          _______________________________________________<br>
          hotspot-gc-use mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a><br>
          <a moz-do-not-send="true"
            href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use"
            target="_blank">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a><br>
        </blockquote>
      </div>
      <br>
    </blockquote>
    <br>
  </body>
</html>