2011-09-05 35 views
4

我有一個運行在glassfish服務器上的巨大應用程序,它創建了大量短期存在的對象,並且我在JVM中具有以下GC配置。JVM由於無限GC而掛起

-XX:+DisableExplicitGC 
-XX:+UseParallelGC 
-XX:+UseParallelOldGC 
-XX:-UseAdaptiveSizePolicy 
-XX:PermSize=256m 
-XX:MaxPermSize=1024m 
-Xms7g 
-Xmx7g 
-XX:NewRatio=2 

但是JVM掛着無限的GC。我必須重新啓動JVM。我從GC日誌中獲得以下信息。

2.855: [GC 734029K->9736K(7034240K), 0.0133500 secs] 
2.869: [Full GC 9736K->9501K(7034240K), 0.1043570 secs] 
13.254: [GC 681231K->26506K(7034240K), 0.0251050 secs] 
13.280: [Full GC 26506K->26082K(7034240K), 0.2904930 secs] 
13.589: [GC 103156K->26224K(7034240K), 0.0015940 secs] 
13.590: [Full GC 26224K->24440K(7034240K), 0.2254710 secs] 
35.478: [GC 1859512K->131673K(7034240K), 0.0781300 secs] 
41.603: [GC 1966745K->351954K(7034240K), 0.1858590 secs] 
46.012: [GC 2187026K->502362K(7034240K), 0.2329020 secs] 
51.850: [GC 2337434K->608654K(7034240K), 0.2012410 secs] 
72.584: [GC 2443726K->727923K(7034240K), 0.2203390 secs] 
80.239: [GC 2562995K->894770K(7034240K), 0.2323490 secs] 
106.221: [GC 2729842K->1265916K(7034240K), 0.2800630 secs] 

請讓我知道jvm GC設置是否適合此用例。或者任何幫助解決這個問題,非常感謝。

更新 我也有jmap堆轉儲信息。 PS即使沒有人使用它,老一代似乎仍然保留着大部分內存。它不會增加(這會在內存泄漏的情況下)。

using thread-local object allocation. 
Parallel GC with 8 thread(s) 

Heap Configuration: 
    MinHeapFreeRatio = 40 
    MaxHeapFreeRatio = 70 
    MaxHeapSize  = 7516192768 (7168.0MB) 
    NewSize   = 5439488 (5.1875MB) 
    MaxNewSize  = 17592186044415 MB 
    OldSize   = 5439488 (5.1875MB) 
    NewRatio   = 2 
    SurvivorRatio = 8 
    PermSize   = 268435456 (256.0MB) 
    MaxPermSize  = 1073741824 (1024.0MB) 

Heap Usage: 
PS Young Generation 
Eden Space: 
    capacity = 2244935680 (2140.9375MB) 
    used  = 863166976 (823.18017578125MB) 
    free  = 1381768704 (1317.75732421875MB) 
    38.44951923076923% used 
From Space: 
    capacity = 112525312 (107.3125MB) 
    used  = 47609824 (45.404266357421875MB) 
    free  = 64915488 (61.908233642578125MB) 
    42.31032392071928% used 
To Space: 
    capacity = 114753536 (109.4375MB) 
    used  = 0 (0.0MB) 
    free  = 114753536 (109.4375MB) 
    0.0% used 
PS Old Generation 
    capacity = 5010817024 (4778.6875MB) 
    used  = 4385643424 (4182.475494384766MB) 
    free  = 625173600 (596.2120056152344MB) 
    87.52351967741699% used 
PS Perm Generation 
    capacity = 458031104 (436.8125MB) 
    used  = 432700088 (412.6549606323242MB) 
    free  = 25331016 (24.15753936767578MB) 
    94.46958606549131% used 
+3

爲什麼使用ParallelOldGC?這難道不比普通的一個更糟嗎? –

+4

我沒有看到任何GC無限的證據。你能否給我們記錄在你殺死它之前發生的事情? –

+2

我同意@Peter Lawrey。這在我看來就像你的應用程序中的一個無限循環。如果我正確地閱讀它,GC日誌顯示JVM每15秒運行垃圾收集器花費的時間就會少於0.3秒。 –

回答

3

您可以取消ParallelOldGC嗎? 它似乎會導致內存碎片。

或者你可以嘗試添加

-XX:+ UseCMSCompactAtFullCollection 和-XX:CMSFullGCsBeforeCompaction = 0

你也可以添加-server 它似乎總是被用於服務器端Java應用程序。

不知道它是否有幫助。因爲我不能 爲你嘗試。

1

不知道有幫助,但你可以使用一個額外的PARAM:

 -XX:ParallelGCThreads=10 //10 threads for GC 

減少GC線程的默認數量。

+2

線程數量是否應等於系統中CPU內核的數量? – AngerClown

+0

@AngerClown這些是專用於GC的線程。您會將此數字設置爲比默認值更低的值,該值可能過高,以便爲實際計算釋放線程。所以你不應該使用可用線程總數的一小部分。 –

0

問題可能是Xmx和Xms都設置爲相同的7g大值。爲什麼不將Xms設置爲較低的值?恕我直言,這應該糾正。

+0

我們也已經嘗試過了。我們將Xms設置爲1G,但我們無法阻止這一點。感謝您的建議。 –