Skip to main content

Why not FullGC ?

4 replies [Last post]
claudio
Offline
Joined: 2003-06-17

System settings:
JDK 6 u12 64 bits
GlassFish v2.1 (9.1.1) (build b60e-fcs)
Linux RHEL 2.6.18-128.1.1.el5

I am seeing memory consumption growing, but full gc is not taking action.
As the MinHeapFreeRatio = 40, full gc should have started, see below at jstat log, the FGC column is 0 and the OLD column is 90% of capacity

<br />
$ jstat -gcutil -t -h 20 2974 15000<br />
Timestamp         S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT<br />
        54736.3   0.00  81.75  67.21  90.39  99.85   1165  132.293     0    0.000  132.293<br />
        54751.3  81.16   0.00  99.33  90.49  99.86   1166  132.515     0    0.000  132.515<br />
        54766.3   0.00 100.00  71.44  90.59  99.87   1167  132.692     0    0.000  132.692<br />
        54781.3  80.58   0.00  38.50  90.67  99.88   1168  132.807     0    0.000  132.807<br />
        54796.3   0.00  69.06   5.97  90.74  99.88   1169  133.140     0    0.000  133.140<br />
        54811.3  70.33  59.48 100.00  90.88  99.89   1171  133.228     0    0.000  133.228<br />
        54826.3  96.97   0.00  96.62  91.00  99.89   1172  133.516     0    0.000  133.516<br />
        54841.4  46.21  80.58 100.00  91.11  99.90   1174  133.603     0    0.000  133.603<br />
        54856.4  69.31   0.00  95.67  91.12  99.90   1174  133.775     0    0.000  133.775<br />
        54871.4   0.00  70.33  85.07  91.19  99.91   1175  133.882     0    0.000  133.882<br />

The vm arguments

<br />
-Dcom.sun.enterprise.server.ss.ASQuickStartup=false<br />
-Djmx.invoke.getters=true<br />
-Dsun.rmi.dgc.client.gcInterval=3600000<br />
-Dsun.rmi.dgc.server.gcInterval=3600000<br />
-XX:+UnlockDiagnosticVMOptions<br />
-XX:+CMSClassUnloadingEnabled<br />
-XX:+AggressiveHeap<br />
-XX:+DisableExplicitGC<br />
-XX:+HeapDumpOnOutOfMemoryError<br />
-Xshare:off<br />
-XX:NewSize=864m<br />
-XX:MaxNewSize=864m<br />
-XX:+UseParallelGC<br />
-XX:+UseParallelOldGC<br />
-XX:MaxPermSize=256m<br />
-Xms6144m<br />
-Xmx6144m<br />
-Xss512k<br />

<br />
$ free<br />
             total       used       free     shared    buffers     cached<br />
Mem:       9983832    8252660    1731172          0      11836    1773512<br />
-/+ buffers/cache:    6467312    3516520<br />
Swap:      4192956         96    4192860<br />

<br />
$ jmap -heap 25724<br />
Attaching to process ID 25724, please wait...<br />
Debugger attached successfully.<br />
Server compiler detected.<br />
JVM version is 11.2-b01</p>
<p>using thread-local object allocation.<br />
Parallel GC with 4 thread(s)</p>
<p>Heap Configuration:<br />
   MinHeapFreeRatio = 40<br />
   MaxHeapFreeRatio = 70<br />
   MaxHeapSize      = 6442450944 (6144.0MB)<br />
   NewSize          = 905969664 (864.0MB)<br />
   MaxNewSize       = 905969664 (864.0MB)<br />
   OldSize          = 5439488 (5.1875MB)<br />
   NewRatio         = 2<br />
   SurvivorRatio    = 8<br />
   PermSize         = 21757952 (20.75MB)<br />
   MaxPermSize      = 268435456 (256.0MB)</p>
<p>Heap Usage:<br />
PS Young Generation<br />
Eden Space:<br />
   capacity = 881065984 (840.25MB)<br />
   used     = 151394872 (144.38140106201172MB)<br />
   free     = 729671112 (695.8685989379883MB)<br />
   17.183147999049297% used<br />
From Space:<br />
   capacity = 11141120 (10.625MB)<br />
   used     = 10485760 (10.0MB)<br />
   free     = 655360 (0.625MB)<br />
   94.11764705882354% used<br />
To Space:<br />
   capacity = 12451840 (11.875MB)<br />
   used     = 0 (0.0MB)<br />
   free     = 12451840 (11.875MB)<br />
   0.0% used<br />
PS Old Generation<br />
   capacity = 5536481280 (5280.0MB)<br />
   used     = 4969305968 (4739.099472045898MB)<br />
   free     = 567175312 (540.9005279541016MB)<br />
   89.7556718190511% used<br />
PS Perm Generation<br />
   capacity = 159383552 (152.0MB)<br />
   used     = 159066000 (151.69715881347656MB)<br />
   free     = 317552 (0.3028411865234375MB)<br />
   99.80076237728721% used<br />

updated formatting

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
briand
Offline
Joined: 2005-07-11

I'm not sure if I completely understand your issue, but it seems to me that you
are expecting that a full gc would have happened by now. If that's the case, then
your expectations are wrong ;-)

The full gc will not happen until an allocation in the old gen (direct by the app,
for certain types of objects, or indirect via promotion during a minor collection)
fails due to a lack of space. At that time, all the application threads will be stopped
and a full collection will occur. So, for you, this won't happen until you see either
the O column or the P column gets to 99.99 (roughly speaking, it actually depends
on the amount of free space available and the size of the object being allocated).

Now, if you want collections to happen more smoothly or frequently, you should consider
using CMS. It runs concurrently with the application, collecting the old gen when certain
usage parameters are reached. Generally, it will start a 'background' collection of the
old gen while the app runs. This CMS Cycle will start when the old gen reaches 60%
utilization (for example, it's tunable and adaptable) and when it completes, the old gen
utilization will drop. However, if CMS can't collect the old gen before the application
consumes the heap space, it will revert to a full collection. Because it run concurrent
with your application, you application's throughput will be reduced while CMS is running.

HTH
Brian

claudio
Offline
Joined: 2003-06-17

Looks like I was expecting a CMS behavior with a Parallel collector.
As MinHeapFreeRatio = 40, I thought "if the free old space hits 40%, then a FullGC should occur".
So, MinHeapFreeRatio only works with CMS collector ?

Thanks

Claudio Miranda

briand
Offline
Joined: 2005-07-11

MinHeapFreeRatio dictates how the serial and parallel garbage collectors
return committed memory back to the system (heap shrink and growth -
which happens when -Xms is different from -Xmx). If the heap utilization
drops below this level, then the collector will return some of the heap pages
back to the OS so other applications can use it. This only happens on full
gc boundaries.

In CMS, what you are looking for is CMSInitiatingOccupancyFraction, and if
you want to disable CMS's adaptive policies and use only the occupancy fraction
as the CMS cycle trigger, then you also want -XX:+UseCMSInitiatingOccupancyOnly,
otherwise CMS will use some past collection history as part of it's decision on when
to start (not that there's anything wrong with that, but some apps want more precise
control).

Brian

claudio
Offline
Joined: 2003-06-17

At 99% OLD use full gc ran.

Any tips ?

[code]
Timestamp S0 S1 E O P YGC YGCT FGC FGCT GCT
56371.6 0.00 66.67 78.39 99.62 99.32 1279 146.305 0 0.000 146.305
56386.7 67.47 0.00 54.58 99.75 99.33 1280 146.426 0 0.000 146.426
56401.7 0.00 68.50 97.72 99.85 99.33 1281 146.524 0 0.000 146.524
56416.7 0.00 0.00 47.00 8.38 54.52 1282 146.627 1 12.132 158.759
56431.7 0.00 100.00 92.24 9.13 54.53 1283 147.030 1 12.132 159.162
56446.7 59.26 0.00 87.37 9.23 54.54 1284 147.134 1 12.132 159.265
56461.7 0.00 33.63 56.13 9.29 54.54 1285 147.182 1 12.132 159.313
[/code]