解釋來自jboss實例的GC日志

Question

我們的生產中發生內存泄漏，我的GC日志如下。 顯然，您可以看到其問題所在。 但是，我無法獲得堆轉儲，因為當我們發現它的問題已經太晚並且堆轉儲失敗時（即使使用-F force選項）。 因此，我試圖找到一種方法來知道何時該崩潰，以便進行堆轉儲。 從這些日志中我能看到什么，幾乎可以證明它即將崩潰嗎？ 謝謝！

Desired survivor size 134217728 bytes, new threshold 19 (max 31)


2430254K->1903326K(2490368K), 0.1973860 secs]
235738.331: [GC
Desired survivor size 134217728 bytes, new threshold 18 (max 31)
 2427614K->1901667K(2490368K), 0.1901241 secs]
235752.709: [GC
Desired survivor size 134217728 bytes, new threshold 17 (max 31)
 2425955K->1915547K(2490368K), 0.2188464 secs]
235761.054: [GC
Desired survivor size 134217728 bytes, new threshold 16 (max 31)
 2439835K->1908633K(2490368K), 0.2318097 secs]
235772.360: [GC
Desired survivor size 134217728 bytes, new threshold 15 (max 31)
 2432921K->1911872K(2490368K), 0.2773868 secs]
235785.063: [GC-- 2436160K->2479951K(2490368K), 1.1930829 secs]
235786.257: [Full GC 2479951K->1648025K(2490368K), 14.7565160 secs]
235802.763: [GC
Desired survivor size 134217728 bytes, new threshold 14 (max 31)
 2172313K->1732187K(2490368K), 0.1365330 secs]
235813.227: [GC
Desired survivor size 134217728 bytes, new threshold 13 (max 31)
 2256475K->1707125K(2490368K), 0.1693956 secs]
235825.499: [GC
Desired survivor size 134217728 bytes, new threshold 12 (max 31)
 2231413K->1701399K(2490368K), 0.1122006 secs]
235837.714: [GC
Desired survivor size 134217728 bytes, new threshold 11 (max 31)
 2225687K->1719535K(2490368K), 0.1651736 secs]
235852.926: [GC
Desired survivor size 134217728 bytes, new threshold 10 (max 31)
 2243823K->1710722K(2490368K), 0.1077586 secs]
235868.371: [GC
Desired survivor size 134217728 bytes, new threshold 9 (max 31)
 2235010K->1714245K(2490368K), 0.1573498 secs]
235887.277: [GC
Desired survivor size 134217728 bytes, new threshold 8 (max 31)
 2238533K->1707476K(2490368K), 0.1199396 secs]
235900.744: [GC
Desired survivor size 134217728 bytes, new threshold 7 (max 31)
 2231764K->1706693K(2490368K), 0.2301796 secs]
235917.022: [GC
Desired survivor size 134217728 bytes, new threshold 6 (max 31)
 2230981K->1708947K(2490368K), 0.1099928 secs]
235927.712: [GC
Desired survivor size 134217728 bytes, new threshold 5 (max 31)
 2233235K->1729423K(2490368K), 0.1288758 secs]
235944.467: [GC
Desired survivor size 134217728 bytes, new threshold 4 (max 31)
 2253711K->1713068K(2490368K), 0.1224733 secs]
235957.965: [GC
Desired survivor size 134217728 bytes, new threshold 3 (max 31)
 2237356K->1721180K(2490368K), 0.1311912 secs]
235973.956: [GC
Desired survivor size 134217728 bytes, new threshold 2 (max 31)
 2245468K->1735845K(2490368K), 0.1293705 secs]
235988.761: [GC
Desired survivor size 134217728 bytes, new threshold 1 (max 31)
 2260133K->1725458K(2490368K), 0.0830605 secs]
236009.097: [GC
Desired survivor size 134217728 bytes, new threshold 1 (max 31)
 2249746K->1723956K(2490368K), 0.1006387 secs]
236021.587: [GC
Desired survivor size 134217728 bytes, new threshold 1 (max 31)
 2248244K->1732905K(2490368K), 0.1065915 secs]
236039.245: [GC
Desired survivor size 130154496 bytes, new threshold 2 (max 31)
 2257193K->1747624K(2494336K), 0.1222832 secs]
236048.721: [GC
Desired survivor size 124583936 bytes, new threshold 3 (max 31)
 2275880K->1748480K(2490368K), 0.1463785 secs]
236060.974: [GC
Desired survivor size 120127488 bytes, new threshold 4 (max 31)
 2276736K->1743277K(2504128K), 0.3267914 secs]
236067.175: [GC
Desired survivor size 134217728 bytes, new threshold 3 (max 31)
 2290733K->1926829K(2499776K), 0.2225210 secs]
236067.398: [Full GC 1926829K->1896112K(2499776K), 12.3642659 secs]
236081.066: [Full GC 2382464K->1961344K(2499776K), 13.0067024 secs]
236095.026: [Full GC 2382463K->1972662K(2499776K), 12.6296210 secs]
236108.585: [Full GC 2382463K->1891859K(2499776K), 14.3240448 secs]
236123.974: [Full GC 2382463K->1958937K(2499776K), 13.2175196 secs]
236138.415: [Full GC 2382463K->2004901K(2499776K), 13.5869753 secs]
236153.869: [Full GC 2382463K->2034151K(2499776K), 14.5268706 secs]
236169.379: [Full GC 2382463K->1981368K(2499776K), 17.8114037 secs]
236188.164: [Full GC 2382463K->2019591K(2499776K), 17.3729262 secs]
236206.151: [Full GC 2382464K->2054701K(2499776K), 17.2837183 secs]
236224.275: [Full GC 2382464K->2086992K(2499776K), 18.0917252 secs]
236242.927: [Full GC 2382464K->2007157K(2499776K), 18.8760425 secs]
236262.701: [Full GC 2382463K->2088662K(2499776K), 18.0601789 secs]
236281.380: [Full GC 2382463K->2120933K(2499776K), 19.5213884 secs]
236301.719: [Full GC 2382463K->2142691K(2499776K), 19.8563379 secs]
236322.349: [Full GC 2382463K->2093867K(2499776K), 23.5206669 secs]
236346.683: [Full GC 2382464K->2141437K(2499776K), 21.5340729 secs]
236368.895: [Full GC 2382464K->2165122K(2499776K), 20.9653757 secs]
236390.663: [Full GC 2373194K->2187083K(2499776K), 21.7935591 secs]
236413.582: [Full GC 2382464K->2162963K(2499776K), 22.9974370 secs]
236437.187: [Full GC 2382463K->2209939K(2499776K), 21.7474342 secs]
236459.506: [Full GC 2382463K->2208399K(2499776K), 21.1459454 secs]
236481.136: [Full GC 2382463K->2211743K(2499776K), 20.7020540 secs]
236502.553: [Full GC 2382463K->2174831K(2499776K), 23.5576392 secs]
236527.434: [Full GC 2382464K->2210273K(2499776K), 21.3455734 secs]
236549.321: [Full GC 2382464K->2220642K(2499776K), 20.4743578 secs]
236570.593: [Full GC 2382464K->2226068K(2499776K), 19.7456885 secs]
236590.796: [Full GC 2382464K->2170462K(2499776K), 22.6452983 secs]
236614.818: [Full GC 2382463K->2198514K(2499776K), 18.0114350 secs]
236633.619: [Full GC 2382463K->2224056K(2499776K), 20.3950715 secs]
236654.872: [Full GC 

這是我的JVM選項，我們正在使用Java 1.6。 這是針對一個高流量的電子商務網站，每月有大約1500萬訪客。 有什么想法嗎？

 Xmx2560m -Xms2560m -Xss512k -XX:NewSize=768m -XX:MaxNewSize=768m -XX:MaxPermSize=512m -    XX:ParallelGCThreads=20 -XX:+UseParallelGC -XX:SurvivorRatio=4 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31 -Dsun.rmi.dgc.c
lient.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 - Dsun.lang.ClassLoader.allowArraySyntax=true

Answer 1

您可以將-XX:+HeapDumpOnOutOfMemoryError用作JBoss啟動的Java選項。 發生內存不足錯誤時，這將轉儲堆。 另外，您可能還需要指定-XX:HeapDumpPath來指定轉儲文件所在的位置（例如， -XX:HeapDumpPath=/disk2/dumps ）

最后，可以考慮使用類似的工具HPjmeter想象你在你的問題粘貼loggc數據。

Answer 2

您也可以嘗試打印“類直方圖”，以查看哪些類占據了堆。 打印直方圖比轉儲整個堆要輕。

1. 比較完整GC之前/之后的實例數。 這可以告訴您是否存在完全GC無法收集的任何實例。 啟用：

   -XX：+ PrintClassHistogramBeforeFullGC -XX：+ PrintClassHistogramBeforeFullGC

2. 然后，您可以在Full GC命中之前拍攝直方圖快照，以查看在應用程序運行期間是否有任何可疑的類實例繼續增長：

   jmap -histo $ pid

更新 ：您還可以使用jstat收集有關每個堆內存區域的stats信息，也許您將能夠檢測到一些分配模式：

jstat -gcutil -t <pid> <interval> <number_of_samples>