快捷導(dǎo)航

jvm垃圾回收GC調(diào)優(yōu)基礎(chǔ)原理分析

更新時間：2022年01月25日 11:10:54 作者：金色夢想

談到調(diào)優(yōu)，這一定是針對特定場景、特定目的的事情，對于 GC 調(diào)優(yōu)來說，首先就需要清楚調(diào)優(yōu)的目標(biāo)是什么？從性能的角度看，通常關(guān)注三個方面，內(nèi)存占用（footprint）、延時（latency）和吞吐量（throughput）

GC調(diào)優(yōu)(Tuning Garbage Collection)和其他性能調(diào)優(yōu)是同樣的原理。初學(xué)者可能會被 200 多個 GC參數(shù)弄得一頭霧水, 然后隨便調(diào)整幾個來試試結(jié)果,又或者修改幾行代碼來測試。其實只要參照下面的步驟，就能保證你的調(diào)優(yōu)方向正確:

列出性能調(diào)優(yōu)指標(biāo)(State your performance goals)
執(zhí)行測試(Run tests)
檢查結(jié)果(Measure the results)
與目標(biāo)進(jìn)行對比(Compare the results with the goals)
如果達(dá)不到指標(biāo), 修改配置參數(shù), 然后繼續(xù)測試(go back to running tests)

第一步, 我們需要做的事情就是: 制定明確的GC性能指標(biāo)。對所有性能監(jiān)控和管理來說, 有三個維度是通用的:

Latency(延遲)
Throughput(吞吐量)
Capacity(系統(tǒng)容量)

我們先講解基本概念,然后再演示如何使用這些指標(biāo)。如果您對延遲、吞吐量和系統(tǒng)容量等概念很熟悉, 可以跳過這一小節(jié)。

核心概念(Core Concepts)

我們先來看一家工廠的裝配流水線。工人在流水線將現(xiàn)成的組件按順序拼接,組裝成自行車。通過實地觀測, 我們發(fā)現(xiàn)從組件進(jìn)入生產(chǎn)線，到另一端組裝成自行車需要4小時。

繼續(xù)觀察,我們還發(fā)現(xiàn),此后每分鐘就有1輛自行車完成組裝, 每天24小時,一直如此。將這個模型簡化, 并忽略維護(hù)窗口期后得出結(jié)論：這條流水線每小時可以組裝60輛自行車。

說明: 時間窗口/窗口期，請類比車站賣票的窗口，是一段規(guī)定/限定做某件事的時間段。

通過這兩種測量方法, 就知道了生產(chǎn)線的相關(guān)性能信息：延遲與吞吐量:

生產(chǎn)線的延遲: 4小時
生產(chǎn)線的吞吐量: 60輛/小時

請注意, 衡量延遲的時間單位根據(jù)具體需要而確定 —— 從納秒(nanosecond)到幾千年(millennia)都有可能。系統(tǒng)的吞吐量是每個單位時間內(nèi)完成的操作。操作(Operations)一般是特定系統(tǒng)相關(guān)的東西。在本例中,選擇的時間單位是小時, 操作就是對自行車的組裝。

掌握了延遲和吞吐量兩個概念之后, 讓我們對這個工廠來進(jìn)行實際的調(diào)優(yōu)。自行車的需求在一段時間內(nèi)都很穩(wěn)定, 生產(chǎn)線組裝自行車有四個小時延遲, 而吞吐量在幾個月以來都很穩(wěn)定: 60輛/小時。假設(shè)某個銷售團(tuán)隊突然業(yè)績暴漲, 對自行車的需求增加了1倍?？蛻裘刻煨枰淖孕熊嚥辉偈?60 24 = 1440輛, 而是 21440 = 2880輛/天。老板對工廠的產(chǎn)能不滿意，想要做些調(diào)整以提升產(chǎn)能。

看起來總經(jīng)理很容易得出正確的判斷, 系統(tǒng)的延遲沒法子進(jìn)行處理 —— 他關(guān)注的是每天的自行車生產(chǎn)總量。得出這個結(jié)論以后, 假若工廠資金充足, 那么應(yīng)該立即采取措施, 改善吞吐量以增加產(chǎn)能。

我們很快會看到, 這家工廠有兩條相同的生產(chǎn)線。每條生產(chǎn)線一分鐘可以組裝一輛成品自行車。可以想象，每天生產(chǎn)的自行車數(shù)量會增加一倍。達(dá)到 2880輛/天。要注意的是, 不需要減少自行車的裝配時間 —— 從開始到結(jié)束依然需要 4 小時。

巧合的是，這樣進(jìn)行的性能優(yōu)化,同時增加了吞吐量和產(chǎn)能。一般來說，我們會先測量當(dāng)前的系統(tǒng)性能, 再設(shè)定新目標(biāo), 只優(yōu)化系統(tǒng)的某個方面來滿足性能指標(biāo)。

在這里做了一個很重要的決定 —— 要增加吞吐量,而不是減小延遲。在增加吞吐量的同時, 也需要增加系統(tǒng)容量。比起原來的情況, 現(xiàn)在需要兩條流水線來生產(chǎn)出所需的自行車。在這種情況下, 增加系統(tǒng)的吞吐量并不是免費的, 需要水平擴(kuò)展, 以滿足增加的吞吐量需求。

在處理性能問題時, 應(yīng)該考慮到還有另一種看似不相關(guān)的解決辦法。假如生產(chǎn)線的延遲從1分鐘降低為30秒,那么吞吐量同樣可以增長 1 倍。

或者是降低延遲, 或者是客戶非常有錢。軟件工程里有一種相似的說法 —— 每個性能問題背后,總有兩種不同的解決辦法。可以用更多的機(jī)器, 或者是花精力來改善性能低下的代碼。

Latency(延遲)

GC的延遲指標(biāo)由一般的延遲需求決定。延遲指標(biāo)通常如下所述:

所有交易必須在10秒內(nèi)得到響應(yīng)
90%的訂單付款操作必須在3秒以內(nèi)處理完成
推薦商品必須在 100 ms 內(nèi)展示到用戶面前

面對這類性能指標(biāo)時, 需要確保在交易過程中, GC暫停不能占用太多時間，否則就滿足不了指標(biāo)。“不能占用太多” 的意思需要視具體情況而定, 還要考慮到其他因素, 比如外部數(shù)據(jù)源的交互時間(round-trips), 鎖競爭(lock contention), 以及其他的安全點等等。

假設(shè)性能需求為: 90%的交易要在 1000ms 以內(nèi)完成, 每次交易最長不能超過 10秒。根據(jù)經(jīng)驗, 假設(shè)GC暫停時間比例不能超過10%。也就是說, 90%的GC暫停必須在 100ms 內(nèi)結(jié)束, 也不能有超過 1000ms 的GC暫停。為簡單起見, 我們忽略在同一次交易過程中發(fā)生多次GC停頓的可能性。

有了正式的需求,下一步就是檢查暫停時間。有許多工具可以使用, 在接下來的 6. GC 調(diào)優(yōu)(工具篇) 中會進(jìn)行詳細(xì)的介紹, 在本節(jié)中我們通過查看GC日志, 檢查一下GC暫停的時間。相關(guān)的信息散落在不同的日志片段中, 看下面的數(shù)據(jù):

****-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics)
[PSYoungGen: 93677K->70109K(254976K)]
[ParOldGen: 499597K->511230K(761856K)]
593275K->581339K(1016832K),
[Metaspace: 2936K->2936K(1056768K)]
, 0.0713174 secs]
[Times: user=0.21 sys=0.02, real=0.07 secs

這表示一次GC暫停, 在 ****-06-04T13:34:16 這個時刻觸發(fā). 對應(yīng)于JVM啟動之后的 2,578 ms。

此事件將應(yīng)用線程暫停了 0.0713174 秒。雖然花費的總時間為 210 ms, 但因為是多核CPU機(jī)器, 所以最重要的數(shù)字是應(yīng)用線程被暫停的總時間, 這里使用的是并行GC, 所以暫停時間大約為 70ms 。這次GC的暫停時間小于 100ms 的閾值，滿足需求。

繼續(xù)分析, 從所有GC日志中提取出暫停相關(guān)的數(shù)據(jù), 匯總之后就可以得知是否滿足需求。

Throughput(吞吐量)

吞吐量和延遲指標(biāo)有很大區(qū)別。當(dāng)然兩者都是根據(jù)一般吞吐量需求而得出的。一般吞吐量需求(Generic requirements for throughput) 類似這樣:

解決方案每天必須處理 100萬個訂單
解決方案必須支持1000個登錄用戶,同時在5-10秒內(nèi)執(zhí)行某個操作: A、B或C
每周對所有客戶進(jìn)行統(tǒng)計, 時間不能超過6小時，時間窗口為每周日晚12點到次日6點之間。

可以看出,吞吐量需求不是針對單個操作的, 而是在給定的時間內(nèi), 系統(tǒng)必須完成多少個操作。和延遲需求類似, GC調(diào)優(yōu)也需要確定GC行為所消耗的總時間。每個系統(tǒng)能接受的時間不同, 一般來說, GC占用的總時間比不能超過 10%。

現(xiàn)在假設(shè)需求為: 每分鐘處理 1000 筆交易。同時, 每分鐘GC暫停的總時間不能超過6秒(即10%)。

有了正式的需求, 下一步就是獲取相關(guān)的信息。依然是從GC日志中提取數(shù)據(jù), 可以看到類似這樣的信息:

****-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics)
[PSYoungGen: 93677K->70109K(254976K)]
[ParOldGen: 499597K->511230K(761856K)]
593275K->581339K(1016832K),
[Metaspace: 2936K->2936K(1056768K)],
0.0713174 secs]
[Times: user=0.21 sys=0.02, real=0.07 secs

此時我們對用戶耗時(user)和系統(tǒng)耗時(sys)感興趣, 而不關(guān)心實際耗時(real)。在這里, 我們關(guān)心的時間為 0.23s(user + sys = 0.21 + 0.02 s), 這段時間內(nèi), GC暫停占用了 cpu 資源。重要的是, 系統(tǒng)運行在多核機(jī)器上, 轉(zhuǎn)換為實際的停頓時間(stop-the-world)為 0.0713174秒, 下面的計算會用到這個數(shù)字。

提取出有用的信息后, 剩下要做的就是統(tǒng)計每分鐘內(nèi)GC暫停的總時間?？纯词欠駶M足需求: 每分鐘內(nèi)總的暫停時間不得超過6000毫秒(6秒)。

Capacity(系統(tǒng)容量)

系統(tǒng)容量(Capacity)需求,是在達(dá)成吞吐量和延遲指標(biāo)的情況下,對硬件環(huán)境的額外約束。這類需求大多是來源于計算資源或者預(yù)算方面的原因。例如:

系統(tǒng)必須能部署到小于512 MB內(nèi)存的Android設(shè)備上
系統(tǒng)必須部署在Amazon EC2實例上, 配置不得超過 c3.xlarge(4核8GB)。
每月的 Amazon EC2 賬單不得超過 $12,000

因此, 在滿足延遲和吞吐量需求的基礎(chǔ)上必須考慮系統(tǒng)容量。可以說, 假若有無限的計算資源可供揮霍, 那么任何延遲和吞吐量指標(biāo) 都不成問題, 但現(xiàn)實情況是, 預(yù)算(budget)和其他約束限制了可用的資源。

相關(guān)示例

介紹完性能調(diào)優(yōu)的三個維度后, 我們來進(jìn)行實際的操作以達(dá)成GC性能指標(biāo)。

請看下面的代碼:

//imports skipped for brevity
public class Producer implements Runnable {
  private static ScheduledExecutorService executorService
         = Executors.newScheduledThreadPool(2);
  private Deque<byte[]> deque;
  private int objectSize;
  private int queueSize;
  public Producer(int objectSize, int ttl) {
    this.deque = new ArrayDeque<byte[]>();
    this.objectSize = objectSize;
    this.queueSize = ttl * 1000;
  }
  @Override
  public void run() {
    for (int i = 0; i < 100; i++) { 
        deque.add(new byte[objectSize]); 
        if (deque.size() > queueSize) {
            deque.poll();
        }
    }
  }
  public static void main(String[] args) 
        throws InterruptedException {
    executorService.scheduleAtFixedRate(
        new Producer(200 * 1024 * 1024 / 1000, 5), 
        0, 100, TimeUnit.MILLISECONDS
    );
    executorService.scheduleAtFixedRate(
        new Producer(50 * 1024 * 1024 / 1000, 120), 
        0, 100, TimeUnit.MILLISECONDS);
    TimeUnit.MINUTES.sleep(10);
    executorService.shutdownNow();
  }
}

這段程序代碼, 每 100毫秒提交兩個作業(yè)(job)來。每個作業(yè)都模擬特定的生命周期: 創(chuàng)建對象, 然后在預(yù)定的時間釋放, 接著就不管了, 由GC來自動回收占用的內(nèi)存。

在運行這個示例程序時，通過以下JVM參數(shù)打開GC日志記錄:

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps

還應(yīng)該加上JVM參數(shù) -Xloggc以指定GC日志的存儲位置,類似這樣:

-Xloggc:C:\\Producer_gc.log

在日志文件中可以看到GC的行為, 類似下面這樣:

****-06-04T13:34:16.119-0200: 1.723: [GC (Allocation Failure) 
        [PSYoungGen: 114016K->73191K(234496K)] 
    421540K->421269K(745984K), 
    0.0858176 secs] 
    [Times: user=0.04 sys=0.06, real=0.09 secs] 
****-06-04T13:34:16.738-0200: 2.342: [GC (Allocation Failure) 
        [PSYoungGen: 234462K->93677K(254976K)] 
    582540K->593275K(766464K), 
    0.2357086 secs] 
    [Times: user=0.11 sys=0.14, real=0.24 secs] 
****-06-04T13:34:16.974-0200: 2.578: [Full GC (Ergonomics) 
        [PSYoungGen: 93677K->70109K(254976K)] 
        [ParOldGen: 499597K->511230K(761856K)] 
    593275K->581339K(1016832K), 
        [Metaspace: 2936K->2936K(1056768K)], 
    0.0713174 secs] 
    [Times: user=0.21 sys=0.02, real=0.07 secs]

基于日志中的信息, 可以通過三個優(yōu)化目標(biāo)來提升性能:

確保最壞情況下,GC暫停時間不超過預(yù)定閥值
確保線程暫停的總時間不超過預(yù)定閥值
在確保達(dá)到延遲和吞吐量指標(biāo)的情況下, 降低硬件配置以及成本。

為此, 用三種不同的配置, 將代碼運行10分鐘, 得到了三種不同的結(jié)果, 匯總?cè)缦?

堆內(nèi)存大小(Heap)	GC算法(GC Algorithm)	有效時間比(Useful work)	最長停頓時間(Longest pause)
-Xmx12g	-XX:+UseConcMarkSweepGC	89.8%	560 ms
-Xmx12g	-XX:+UseParallelGC	91.5%	1,104 ms
-Xmx8g	-XX:+UseConcMarkSweepGC	66.3%	1,610 ms

使用不同的GC算法,和不同的內(nèi)存配置,運行相同的代碼, 以測量GC暫停時間與延遲、吞吐量的關(guān)系。實驗的細(xì)節(jié)和結(jié)果在后面章節(jié)詳細(xì)介紹。

注意, 為了盡量簡單, 示例中只改變了很少的輸入?yún)?shù), 此實驗也沒有在不同CPU數(shù)量或者不同的堆布局下進(jìn)行測試。

Tuning for Latency(調(diào)優(yōu)延遲指標(biāo))

假設(shè)有一個需求, 每次作業(yè)必須在 1000ms 內(nèi)處理完成。我們知道, 實際的作業(yè)處理只需要100 ms，簡化后，兩者相減就可以算出對 GC暫停的延遲要求。現(xiàn)在需求變成: GC暫停不能超過900ms。這個問題很容易找到答案, 只需要解析GC日志文件, 并找出GC暫停中最大的那個暫停時間即可。

再來看測試所用的三個配置:

堆內(nèi)存大小(Heap)	GC算法(GC Algorithm)	有效時間比(Useful work)	最長停頓時間(Longest pause)
-Xmx12g	-XX:+UseConcMarkSweepGC	89.8%	560 ms
-Xmx12g	-XX:+UseParallelGC	91.5%	1,104 ms
-Xmx8g	-XX:+UseConcMarkSweepGC	66.3%	1,610 ms

可以看到,其中有一個配置達(dá)到了要求。運行的參數(shù)為:

java -Xmx12g -XX:+UseConcMarkSweepGC Producer

對應(yīng)的GC日志中,暫停時間最大為 560 ms, 這達(dá)到了延遲指標(biāo) 900 ms 的要求。如果還滿足吞吐量和系統(tǒng)容量需求的話,就可以說成功達(dá)成了GC調(diào)優(yōu)目標(biāo), 調(diào)優(yōu)結(jié)束。

Tuning for Throughput(吞吐量調(diào)優(yōu))

假定吞吐量指標(biāo)為: 每小時完成 1300萬次操作處理。同樣是上面的配置, 其中有一種配置滿足了需求:

堆內(nèi)存大小(Heap)	GC算法(GC Algorithm)	有效時間比(Useful work)	最長停頓時間(Longest pause)
-Xmx12g	-XX:+UseConcMarkSweepGC	89.8%	560 ms
-Xmx12g	-XX:+UseParallelGC	91.5%	1,104 ms
-Xmx8g	-XX:+UseConcMarkSweepGC	66.3%	1,610 ms

此配置對應(yīng)的命令行參數(shù)為:

java -Xmx12g -XX:+UseParallelGC Producer

可以看到,GC占用了 8.5%的CPU時間,剩下的 91.5% 是有效的計算時間。為簡單起見, 忽略示例中的其他安全點。現(xiàn)在需要考慮:

每個CPU核心處理一次作業(yè)需要耗時 100ms
因此, 一分鐘內(nèi)每個核心可以執(zhí)行 60,000 次操作(每個job完成100次操作)
一小時內(nèi), 一個核心可以執(zhí)行 360萬次操作
有四個CPU內(nèi)核, 則每小時可以執(zhí)行: 4 x 3.6M = 1440萬次操作

理論上，通過簡單的計算就可以得出結(jié)論, 每小時可以執(zhí)行的操作數(shù)為: 次, 滿足需求。

值得一提的是, 假若還要滿足延遲指標(biāo), 那就有問題了, 最壞情況下, GC暫停時間為 1,104 ms最大延遲時間是前一種配置的兩倍。

Tuning for Capacity(調(diào)優(yōu)系統(tǒng)容量)

假設(shè)需要將軟件部署到服務(wù)器上(commodity-class hardware), 配置為 4核10G。這樣的話, 系統(tǒng)容量的要求就變成: 最大的堆內(nèi)存空間不能超過 8GB有了這個需求, 我們需要調(diào)整為第三套配置進(jìn)行測試:

堆內(nèi)存大小(Heap)	GC算法(GC Algorithm)	有效時間比(Useful work)	最長停頓時間(Longest pause)
-Xmx12g	-XX:+UseConcMarkSweepGC	89.8%	560 ms
-Xmx12g	-XX:+UseParallelGC	91.5%	1,104 ms
-Xmx8g	-XX:+UseConcMarkSweepGC	66.3%	1,610 ms

程序可以通過如下參數(shù)執(zhí)行:

java -Xmx8g -XX:+UseConcMarkSweepGC Producer

測試結(jié)果是延遲大幅增長, 吞吐量同樣大幅降低:

現(xiàn)在,GC占用了更多的CPU資源, 這個配置只有 66.3%的有效CPU時間。因此,這個配置讓吞吐量從最好的情況 13,176,000 操作/小時下降到不足 9,547,200次操作/小時.
最壞情況下的延遲變成了 1,610 ms, 而不再是 560ms。

通過對這三個維度的介紹, 你應(yīng)該了解, 不是簡單的進(jìn)行“性能(performance)”優(yōu)化, 而是需要從三種不同的維度來進(jìn)行考慮, 測量, 并調(diào)優(yōu)延遲和吞吐量, 此外還需要考慮系統(tǒng)容量的約束。

以上就是jvm垃圾回收GC調(diào)優(yōu)基礎(chǔ)原理分析的詳細(xì)內(nèi)容，更多關(guān)于jvm垃圾回收GC調(diào)優(yōu)的資料請關(guān)注腳本之家其它相關(guān)文章！

原文鏈接：https://plumbr.io/handbook/gc-tuning

您可能感興趣的文章:

欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

軟件下載

源碼下載

軟件編程

網(wǎng)絡(luò)編程

在線工具

數(shù)據(jù)庫

CMS

常用工具

jvm垃圾回收GC調(diào)優(yōu)基礎(chǔ)原理分析

目錄

核心概念(Core Concepts)

Latency(延遲)

Throughput(吞吐量)

Capacity(系統(tǒng)容量)

相關(guān)示例

Tuning for Latency(調(diào)優(yōu)延遲指標(biāo))

Tuning for Throughput(吞吐量調(diào)優(yōu))

Tuning for Capacity(調(diào)優(yōu)系統(tǒng)容量)

相關(guān)文章

最新評論

大家感興趣的內(nèi)容

最近更新的內(nèi)容

常用在線小工具