Вывод журнала сборщика мусора Java CMS

Question

Я использую сборщик мусора Java CMS и пытаюсь понять строки журнала, такие как:

22609.787: [GC 22609.788: [ParNew: 1116101K->79200K(1310720K), 0.2369136 secs]     1551730K->516431K(6029312K), 0.2379422 secs] [Times: user=1.68 sys=0.02, real=0.24 secs] 
22610.741: [Full GC 22610.741: [CMS: 437230K->278442K(4718592K), 14.8596841 secs]   573355K->278442K(6029312K), [CMS Perm : 241468K->236967K(241856K)], 14.8694544 secs]   [Times: user=14.80 sys=0.13, real=14.87 secs] 
22635.415: [GC 22635.416: [ParNew: 1048576K->43613K(1310720K), 0.0904065 secs] 1327018K->322055K(6029312K), 0.0914701 secs] [Times: user=0.45 sys=0.00, real=0.09 secs] 

Основываясь на чтении http://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs, CMS выполнит полную сборку мусора в различных ситуациях (например,если «промоушен при попытке очистки не удастся»), но, согласно этому блогу, в нем будет указана причина полного сбора мусора.

Вместо этого я вижу специальные полные GC.Это определенно CMS, потому что есть другие записи журнала CMS.

Есть ли причины, по которым он будет выполнять полный GC, но не регистрировать причину?

РЕДАКТИРОВАТЬ: Извините, несколько установок Java (I 'унаследовал эту настройку).На самом деле он использует jdk1.6.0_27

EDIT. К сожалению, параметры JVM обернуты в конфигурационные файлы (это коммерческое приложение, которое работает на Tomcat), но я уверен, что они таковы:

min.heapsize=6144m
max.heapsize=6144m
-Xss=512k
-XX:MaxPermSize=512m
-XX:NewSize=1536m 
-XX:MaxNewSize=1536m 
-XX:SurvivorRatio=4 
-XX:+UseConcMarkSweepGC 
-XX:+UseParNewGC 
-XX:+UseTLAB 
-XX:+UseCompressedOops 
-XX:+PrintVMOptions 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCTaskTimeStamps
-XX:+PrintCommandLineFlags 
-XX:+PrintGCApplicationStoppedTime 
-XX:StackShadowPages=20 
-XX:+DisableExplicitGC 

Answer 1

ConcurrentMarkSweepGC выполнит GC, когда определит, что он собирается заполниться, или достигнута отметка низкого уровня воды.(Я не верю, что это так)

Что более вероятно, так это то, что какой-то код вызывает System.gc () напрямую.Например, RMI будет вызывать его каждый час по умолчанию.Вы можете попробовать использовать -XX:+DisableExplicitGC, чтобы увидеть, если это имеет значение.Если это произойдет, я обнаружу причину и остановлю ее (некоторые люди просто оставляют эту опцию включенной).

Другая возможная причина - нехватка свободной прямой памяти.Прямая память очищается только на GC, но не сильно влияет на размер кучи, поэтому похоже, что вам нужен GC.Когда у вас заканчивается прямая память, он должен вызвать System.gc (), чтобы освободить те ByteBuffers, которые его используют.Чтобы обойти это, я могу явно очистить ByteBuffers с прямым отображением и отображением в памяти, чтобы я не иссяк.

Также я бы попробовал обновить Java 6 до 30 или даже Java 7 с обновлением 2, так как он может иметь большепредсказуемое поведение (даже если вы не можете использовать это, оно может быть информативным)

Вы можете попробовать, который может сказать вам, что GC был запущен (но не всегда)

`jstat -gccause {pid} 10s`