我應該如何爲我的應用程序調整CMS？

我們正在使用CMS並遇到併發模式故障（需要大約15秒）。使用JRE 8.

已使用UseCMSInitiatingOccupancyOnly和CMSInitiatingOccupancyFraction（80％）。不使用CMSScavengeBeforeRemark。

分配模式是這樣的：

大量短期對象的分配。所以我們正在使用一個大的年輕一代，2GB。倖存者空間未調整。 MaxTenuringThreshold設置爲15.每隔幾個小時CMS進入。

老一代是4GB。內存使用率很高。每次收集後，老一代擁有約30％的自由空間。不幸的是沒有更多的可用內存我們計劃修改程序以使其佔用較少的內存，但這需要時間。

通常程序沒有太多的工作要做，但每隔幾個小時（我們無法預測何時）我們真的很忙。而15秒的STW太長了。

所以我的問題是：

我們如何調整我們的程序的CMS？

我應該增加老一代（並減少年輕）嗎？

我應該調整Survivor嗎？

我應該改變CMSInitiatingOccupancyFraction嗎？

G1GC會幫忙嗎？

2017-09-28 ntysdd

+ XX：+ UseParallelOldGC？考慮到你有足夠的內核，通常對於小堆來說是更好的選擇。 –

@AlexeyRagozin我們根本不需要STW（除了0.x秒）。如果調優CMS不起作用，我們可能會修改代碼。 – ntysdd

如果您所需要的僅僅是亞秒暫停並且有4GB堆，那麼並行收集器應該能夠做到這一點，前提是您擁有足夠的內核，而不是極其參考繁重的工作負載。 – the8472

老一代是4GB。遇到併發模式故障（大約需要15秒）。

這不完全是一個大堆。如果您遇到單線程的併發模式故障，那麼您可以使用並行收集器來處理該大小。

所以我們正在使用一個大的年輕一代，2GB。

這是相對巨大的，考慮到4GB的整體堆大小，你應該縮小年輕一代，以便老一代擁有超過30％的呼吸空間。。

每隔幾個小時CMS踢

然後，你可以你試過能力運行更頻繁地通過降低IHOP

2017-09-28 12:35:15 the8472

CMS不是壓縮收集器。如果我允許短命的對象太容易進入終身空間，它是不是會破壞堆並強制STW？ – ntysdd

可能更多碎片化，但也有更多的空間容量來處理它 – the8472

回答