<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    Jon,<br>
    <br>
    I haven't looked at the longer log but in general I've found the<br>
    information in the GC logs inadequate to figure out if the<br>
    problem is fragmentation.  But more important, there has<br>
    been some good work in recent versions of hotspot so that<br>
    we're more successful at combating fragmentation.  Try<br>
    the latest release and see if it helps (u26 should be good<br>
    enough).<br>
    <br>
    Jon<br>
    <br>
    On 10/31/11 06:06, Jon Bright wrote:
    <blockquote cite="mid:4EAE9D6E.1060807@siliconcircus.com"
      type="cite">Hi, <br>
      <br>
      We have an application running with a 6GB heap (complete
      parameters below).  Mostly it has a fairly low turnover of memory
      use, but on occasion, it will come under some pressure as it
      reloads a large in-memory data set from a database. <br>
      <br>
      Sometimes in this situation, we'll see a concurrent mode failure.
      Here's one failure: <br>
      <br>
      20021.464: [GC 20021.465: [ParNew: 13093K->3939K(76672K),
      0.0569240 secs]20021.522: [CMS20023.747: [CMS-concurrent-mark:
      11.403/29.029 secs] [Times: user=41.11 sys=1.03, real=29.03 secs]
      <br>
       (concurrent mode failure): 3873922K->2801744K(6206272K),
      30.7900180 secs] 3886215K->2801744K(6282944K), [CMS Perm :
      142884K->142834K(524288K)] icms_dc=33 , 30.8473830 secs]
      [Times: user=30.26 sys=0.71, real=30.85 secs] <br>
      Total time for which application threads were stopped: 30.8484460
      seconds <br>
      <br>
      (I've attached a lengthier log including the previous and
      subsequent CMS collection.) <br>
      <br>
      Am I correct in thinking that this failure can basically only be
      caused by fragmentation?  Both young and old seem to have plenty
      of space. There doesn't seem to be any sign that the tenured
      generation would run out of space before CMS completes. 
      Fragmentation is the only remaining cause that occurs to me. <br>
      <br>
      We're running with 1.6.0_11, although this will be upgraded to
      1.6.0_26 tomorrow.  I realise our current version is ancient - I'm
      not really looking for help on the problem itself, just for advice
      on whether the log line above indicates fragmentation. <br>
      <br>
      Thanks <br>
      <br>
      Jon Bright <br>
      <br>
      <br>
      <br>
      The parameters we have set are: <br>
      <br>
      -server <br>
      -Xmx6144M <br>
      -Xms6144M <br>
      -XX:MaxPermSize=512m <br>
      -XX:PermSize=512m <br>
      -XX:+UseConcMarkSweepGC <br>
      -XX:+CMSIncrementalMode <br>
      -XX:+CMSIncrementalPacing <br>
      -XX:SoftRefLRUPolicyMSPerMB=3 <br>
      -XX:CMSIncrementalSafetyFactor=30 <br>
      -XX:+PrintGCDetails <br>
      -XX:+PrintGCApplicationStoppedTime <br>
      -XX:+PrintGCApplicationConcurrentTime <br>
      -XX:+PrintGCTimeStamps <br>
      -Xloggc:/home/tbmx/log/gc_`date +%Y%m%d%H%M`.log <br>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
hotspot-gc-use mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hotspot-gc-use@openjdk.java.net">hotspot-gc-use@openjdk.java.net</a>
<a class="moz-txt-link-freetext" href="http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use">http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use</a>
</pre>
    </blockquote>
  </body>
</html>