說(shuō)明:

Capacity: 性能,能力,系統(tǒng)容量; 文中翻譯為”系統(tǒng)容量“; 意為硬件配置。

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

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

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

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

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

核心概念(Core Concepts)

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

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

說(shuō)明: 時(shí)間窗口/窗口期，請(qǐng)類(lèi)比車(chē)站賣(mài)票的窗口，是一段規(guī)定/限定做某件事的時(shí)間段。

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

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

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

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

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

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

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

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

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

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

Latency(延遲)

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

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

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

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

有了正式的需求,下一步就是檢查暫停時(shí)間。有許多工具可以使用, 在接下來(lái)的 6. GC 調(diào)優(yōu)(工具篇) 中會(huì)進(jìn)行詳細(xì)的介紹, 在本節(jié)中我們通過(guò)查看GC日志, 檢查一下GC暫停的時(shí)間。相關(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 這個(gè)時(shí)刻觸發(fā). 對(duì)應(yīng)于JVM啟動(dòng)之后的 2,578 ms。

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

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

Throughput(吞吐量)

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

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

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

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

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

****-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

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

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

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

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

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

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

相關(guān)示例

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

請(qǐng)看下面的代碼:

//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毫秒 提交兩個(gè)作業(yè)(job)來(lái)。每個(gè)作業(yè)都模擬特定的生命周期: 創(chuàng)建對(duì)象, 然后在預(yù)定的時(shí)間釋放, 接著就不管了, 由GC來(lái)自動(dòng)回收占用的內(nèi)存。

在運(yùn)行這個(gè)示例程序時(shí)，通過(guò)以下JVM參數(shù)打開(kāi)GC日志記錄:

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

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

-Xloggc:C:\\Producer_gc.log

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

****-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]

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

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

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

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

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

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

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

再來(lái)看測(cè)試所用的三個(gè)配置:

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

java -Xmx12g -XX:+UseConcMarkSweepGC Producer

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

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

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

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

java -Xmx12g -XX:+UseParallelGC Producer

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

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

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

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

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

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

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

java -Xmx8g -XX:+UseConcMarkSweepGC Producer

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

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

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

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

最新評(píng)論