GC調優實戰之過早提升Premature Promotion

Posted on by

過早提升(Premature Promotion)

提升速率(promotion rate), 用於衡量單位時間內從年輕代提升到老年代的數據量。一般使用 MB/sec 作為單位, 和分配速率類似。

JVM會將長時間存活的對象從年輕代提升到老年代。根據分代假設, 可能存在一種情況, 老年代中不僅有存活時間長的對象,也可能有存活時間短的對象。這就是過早提升：對象存活時間還不夠長的時候就被提升到瞭老年代。

major GC 不是為頻繁回收而設計的, 但 major GC 現在也要清理這些生命短暫的對象, 就會導致GC暫停時間過長。這會嚴重影響系統的吞吐量。

如何測量提升速率

可以指定JVM參數 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps , 通過GC日志來測量提升速率. JVM記錄的GC暫停信息如下所示:

0.291: [GC (Allocation Failure)
[PSYoungGen: 33280K->5088K(38400K)]
33280K->24360K(125952K), 0.0365286 secs]
[Times: user=0.11 sys=0.02, real=0.04 secs]
0.446: [GC (Allocation Failure)
[PSYoungGen: 38368K->5120K(71680K)]
57640K->46240K(159232K), 0.0456796 secs]
[Times: user=0.15 sys=0.02, real=0.04 secs]
0.829: [GC (Allocation Failure)
[PSYoungGen: 71680K->5120K(71680K)]
112800K->81912K(159232K), 0.0861795 secs]
[Times: user=0.23 sys=0.03, real=0.09 secs]

從上面的日志可以得知： GC之前和之後的 年輕代使用量以及堆內存使用量。這樣就可以通過差值算出老年代的使用量。GC日志中的信息可以表述為:

Event Time Young decreased Total decreased Promoted Promotion rate
(事件) (耗時) (年輕代減少) (整個堆內存減少) (提升量) (提升速率)
1st GC 291ms 28,192K 8,920K 19,272K 66.2 MB/sec
2nd GC 446ms 33,248K 11,400K 21,848K 140.95 MB/sec
3rd GC 829ms 66,560K 30,888K 35,672K 93.14 MB/sec
Total 829ms     76,792K 92.63 MB/sec

根據這些信息, 就可以計算出觀測周期內的提升速率。平均提升速率為 92 MB/秒, 峰值為 140.95 MB/秒。

請註意, 隻能根據 minor GC 計算提升速率。 Full GC 的日志不能用於計算提升速率, 因為 major GC 會清理掉老年代中的一部分對象。

提升速率的意義

和分配速率一樣, 提升速率也會影響GC暫停的頻率。但分配速率主要影響 minor GC, 而提升速率則影響 major GC 的頻率。有大量的對象提升,自然很快將老年代填滿。 老年代填充的越快, 則 major GC 事件的頻率就會越高。

此前說過, full GC 通常需要更多的時間, 因為需要處理更多的對象, 還要執行碎片整理等額外的復雜過程。

示例

讓我們看一個過早提升的示例。 這個程序創建/獲取大量的對象/數據,並暫存到集合之中, 達到一定數量後進行批處理:

public class PrematurePromotion {
private static final Collection<byte[]> accumulatedChunks
= new ArrayList<>();
private static void onNewChunk(byte[] bytes) {
accumulatedChunks.add(bytes);
if(accumulatedChunks.size() > MAX_CHUNKS) {
processBatch(accumulatedChunks);
accumulatedChunks.clear();
}
}
}

此 Demo 程序 受到過早提升的影響。下文將進行驗證並給出解決辦法。

過早提升的影響

一般來說,過早提升的癥狀表現為以下形式:

  • 短時間內頻繁地執行 full GC。
  • 每次 full GC 後老年代的使用率都很低, 在10-20%或以下。
  • 提升速率接近於分配速率。

要演示這種情況稍微有點麻煩, 所以我們使用特殊手段, 讓對象提升到老年代的年齡比默認情況小很多。指定GC參數 -Xmx24m -XX:NewSize=16m -XX:MaxTenuringThreshold=1, 運行程序之後,可以看到下面的GC日志:

2.176: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 10020K->9042K(12288K)]
19236K->9042K(23040K), 0.0036840 secs]
2.394: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 9042K->8064K(12288K)]
18258K->8064K(23040K), 0.0032855 secs]
2.611: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 8064K->7085K(12288K)]
17280K->7085K(23040K), 0.0031675 secs]
2.817: [Full GC (Ergonomics)
[PSYoungGen: 9216K->0K(10752K)]
[ParOldGen: 7085K->6107K(12288K)]
16301K->6107K(23040K), 0.0030652 secs]

乍一看似乎不是過早提升的問題。事實上,在每次GC之後老年代的使用率似乎在減少。但反過來想, 要是沒有對象提升或者提升率很小, 也就不會看到這麼多的 Full GC 瞭。

簡單解釋一下這裡的GC行為: 有很多對象提升到老年代, 同時老年代中也有很多對象被回收瞭, 這就造成瞭老年代使用量減少的假象. 但事實是大量的對象不斷地被提升到老年代, 並觸發 full GC。

解決方案

簡單來說, 要解決這類問題, 需要讓年輕代存放得下暫存的數據。有兩種簡單的方法:

一是增加年輕代的大小, 設置JVM啟動參數, 類似這樣: -Xmx64m -XX:NewSize=32m, 程序在執行時, Full GC 的次數自然會減少很多, 隻會對 minor GC的持續時間產生影響:

2.251: [GC (Allocation Failure)
[PSYoungGen: 28672K->3872K(28672K)]
37126K->12358K(61440K), 0.0008543 secs]
2.776: [GC (Allocation Failure)
[PSYoungGen: 28448K->4096K(28672K)]
36934K->16974K(61440K), 0.0033022 secs]

二是減少每次批處理的數量, 也能得到類似的結果. 至於選用哪個方案, 要根據業務需求決定。在某些情況下, 業務邏輯不允許減少批處理的數量, 那就隻能增加堆內存,或者重新指定年輕代的大小。

如果都不可行, 就隻能優化數據結構, 減少內存消耗。但總體目標依然是一致的: 讓臨時數據能夠在年輕代存放得下。

以上就是GC調優實戰之過早提升Premature Promotion的詳細內容，更多關於GC調優過早提升的資料請關註WalkonNet其它相關文章！

原文鏈接：https://plumbr.io/handbook/gc-tuning-in-practice#premature-promotion

推薦閱讀：