JVM分鐘長的GC

，如下圖所示，在一切工作像預期的那樣停止對世界的GC操作途中花了60秒。它可以被確定爲一直停止這個世界，因爲（兵馬俑）客戶端丟棄了，抱怨它（兵馬俑服務器）在那段時間內沒有響應。JVM分鐘長的GC

這是年輕/次GC？如果是的話，是否可能是因爲年輕一代的飢餓（伊甸園+倖存者？）。

只有109333（KB）free'd？

我將開始繪製圖形的不同存儲容器，任何其他建議什麼可以做進一步診斷這類問題？

date, startMem=24589884, endMem=24478495, reclaimed=111389, timeTaken=0.211244 (1172274.139: [GC 24589884K->24478495K(29343104K), 0.2112440 secs]) 
date, startMem=24614815, endMem=24505482, reclaimed=109333, timeTaken=61.301987 (1172276.518: [GC 24614815K->24505482K(29343104K), 61.3019860 secs]) 
date, startMem=24641802, endMem=24529546, reclaimed=112256, timeTaken=2.68437 (1172348.921: [GC 24641802K->24529546K(29343104K), 2.6843700 secs])

太陽JVM是1.6，使用以下配置：

-Xms28672m -Xmx28672m -XX：+ UseConcMarkSweepGC -XX：+ PrintGCTimeStamps -XX：+ PrintGC

薩配置調整以進一步調試GC：

'-XX:+PrintGCDateStamps' Print date stamps instead of relative timestamps 
'-XX:+PrintGCDetails' Will show what cpu went for (user, kern), gc algorithm used 
'-XX:+PrintHeapAtGC' will show all of the heaps memory containers and their usage 
'-Xloggc:/path/to/dedicated.log' log to specific file

來源

2013-01-23 user135361

你的應用程序在做什麼？ GC抖動發生在多次掃描中從堆中回收大量內存時，可能每次掃描都會導致更多對象符合採集條件，從而導致進一步掃描。即使是你展示的2秒鐘，GC也需要大量的時間。我想你會發現改變你的應用程序處理對象的方式，而不是JVM配置將成爲你需要的路徑。任何需要保持GC抖動的應用程序都應該考慮重用而不是重新分配對象。 – codeghost

這是一個會話（cookie）存儲。數字，例如「回收」表示實際上回收的內存並不多。如果是這樣，知道原因很方便。我完全同意你的看法，它需要解決（會話）對象如何處理，它們包含什麼等。有一個更好地處理會話的過程，但到目前爲止，我已經找到了工作，找出爲什麼GC會花費+60秒，仍然不會釋放比以前的0.2s gc更多的內存。 – user135361

看看這個博客http://kirk.blog-city.com/why_do_i_have_this_long_gc_pause.htm可能會給你一些指點。 – codeghost

-XX:+UseConcMarkSweepGC使併發收集

Default Vs. CMS

截取是停止的世界相（JVM阻塞）和併發相（JVM執行用戶代碼）的總和的總時間。

您應該啓用詳細GC日誌記錄，以進一步調查，因爲你不知道有多少的那60秒卡住JVM信息。

來源

2013-01-28 17:39:47 fglez

我已經概述了更詳細的輸出將被記錄。問題不在於CMS如何工作，而在於什麼情況下會出現一個長期停止世界。 JVM一直被阻塞，所以它是一個「重要的GC」，可能是因爲碎片整理。如果是這樣，問題是如何知道添加更多的堆是否有用，或者在什麼情況下會安排cms在早期的幫助中啓用。我很欣賞你的嘗試，但是在我向你提供幫助之前，你將不得不對這些因素進行隔離。 – user135361

你怎麼知道JVM在沒有詳細日誌的情況下被封鎖了整個時間？您應該將所有信息添加到問題中。 – fglez

好點，更新。 – user135361

回答

相關問題