高并發(fā)場景下JVM調(diào)優(yōu)實踐之路

作者：vivo互聯(lián)網(wǎng)技術(shù)團(tuán)隊Li Guanyun、 Jessica Chen

一、背景

2021年2月，收到反饋，視頻APP某核心接口高峰期響應(yīng)慢，影響用戶體驗。

通過監(jiān)控發(fā)現(xiàn)，接口響應(yīng)慢主要是P99耗時高引起的，懷疑與該服務(wù)的GC有關(guān)，該服務(wù)典型的一個實例GC表現(xiàn)如下圖：

可以看出，在觀察周期里：

• 平均每10分鐘Young GC次數(shù)66次，峰值為470次；

• 平均每10分鐘Full GC次數(shù)0.25次，峰值5次；
  
  

可見Full GC非常頻繁，Young GC在特定的時段也比較頻繁，存在較大的優(yōu)化空間。由于對GC停頓的優(yōu)化是降低接口的P99時延一個有效的手段，所以決定對該核心服務(wù)進(jìn)行JVM調(diào)優(yōu)。

二、優(yōu)化目標(biāo)

• 接口P99時延降低30%

• 減少Young GC和Full GC次數(shù)、停頓時長、單次停頓時長

由于GC的行為與并發(fā)有關(guān)，例如當(dāng)并發(fā)比較高時，不管如何調(diào)優(yōu)，Young GC總會很頻繁，總會有不該晉升的對象晉升觸發(fā)Full GC，因此優(yōu)化的目標(biāo)根據(jù)負(fù)載分別制定：

目標(biāo)1：高負(fù)載（單機1000 QPS以上）

• Young GC次數(shù)減少20%-30% ，Young GC累積耗時不惡化；

• Full GC次數(shù)減少50%以上，單次、累積Full GC耗時減少50%以上，服務(wù)發(fā)布不觸發(fā)Full GC。

目標(biāo)2：中負(fù)載（單機500-600）

• Young GC次數(shù)減少20%-30% ，Young GC累積耗時減少20%；

• Full GC次數(shù)不高于4次/天，服務(wù)發(fā)布不觸發(fā)Full GC。

目標(biāo)3：低負(fù)載（單機200 QPS以下）

• Young GC次數(shù)減少20%-30% ，Young GC累積耗時減少20%；

• Full GC次數(shù)不高于1次/天，服務(wù)發(fā)布不觸發(fā)Full GC。

三、當(dāng)前存在的問題

當(dāng)前服務(wù)的JVM配置參數(shù)如下：

-Xms4096M -Xmx4096M -Xmn1024M-XX:PermSize=512M-XX:MaxPermSize=512M

單純從參數(shù)上分析，存在以下問題：

未顯示指定收集器?

JDK 8默認(rèn)搜集器為ParrallelGC，即Young區(qū)采用Parallel Scavenge，老年代采用Parallel Old進(jìn)行收集，這套配置的特點是吞吐量優(yōu)先，一般適用于后臺任務(wù)型服務(wù)器。

比如批量訂單處理、科學(xué)計算等對吞吐量敏感，對時延不敏感的場景，當(dāng)前服務(wù)是視頻與用戶交互的門戶，對時延非常敏感，因此不適合使用默認(rèn)收集器ParrallelGC，應(yīng)選擇更合適的收集器。

Young區(qū)配比不合理

當(dāng)前服務(wù)主要提供API，這類服務(wù)的特點是常駐對象會比較少，絕大多數(shù)對象的生命周期都比較短，經(jīng)過一次或兩次Young GC就會消亡。

再看下當(dāng)前JVM配置：

整個堆為4G，Young區(qū)總共1G，默認(rèn)-XX:SurvivorRatio=8，即有效大小為0.9G，老年代常駐對象大小約400M。

這就意味著，當(dāng)服務(wù)負(fù)載較高，請求并發(fā)較大時，Young區(qū)中Eden S0區(qū)域會迅速填滿，進(jìn)而Young GC會比較頻繁。

另外會引起本應(yīng)被Young GC回收的對象過早晉升，增加Full GC的頻率，同時單次收集的區(qū)域也會增大，由于Old區(qū)使用的是ParralellOld，無法與用戶線程并發(fā)執(zhí)行，導(dǎo)致服務(wù)長時間停頓，可用性下降， P99響應(yīng)時間上升。

未設(shè)置

-XX:MetaspaceSize和-XX:MaxMetaspaceSize

Perm區(qū)在jdk?1.8已經(jīng)過時，被Meta區(qū)取代，因此-XX:PermSize=512M -XX:MaxPermSize=512M配置會被忽略，真正控制Meta區(qū)GC的參數(shù)為-XX:MetaspaceSize:Metaspace初始大小，64位機器默認(rèn)為21M左右 -XX:MaxMetaspaceSize:Metaspace的最大值，64位機器默認(rèn)為18446744073709551615Byte，可以理解為無上限 -XX:MaxMetaspaceExpansion:增大觸發(fā)metaspace GC閾值的最大要求 -XX:MinMetaspaceExpansion:增大觸發(fā)metaspace GC閾值的最小要求，默認(rèn)為340784Byte

這樣服務(wù)在啟動和發(fā)布的過程中，元數(shù)據(jù)區(qū)域達(dá)到21M時會觸發(fā)一次Full GC (Metadata GC Threshold)，隨后隨著元數(shù)據(jù)區(qū)域的擴(kuò)張，會夾雜若干次Full GC (Metadata GC Threshold)，使服務(wù)發(fā)布穩(wěn)定性和效率下降。

此外如果服務(wù)使用了大量動態(tài)類生成技術(shù)的話，也會因為這個機制產(chǎn)生不必要的Full GC (Metadata GC Threshold)。

四、優(yōu)化方案/驗證方案

上面已分析出當(dāng)前配置存在的較為明顯的不足，下面優(yōu)化方案主要先針對性解決這些問題，之后再結(jié)合效果決定是否繼續(xù)深入優(yōu)化。

當(dāng)前主流/優(yōu)秀的搜集器包含：

• Parrallel Scavenge Parrallel Old：吞吐量優(yōu)先，后臺任務(wù)型服務(wù)適合；

• ParNew CMS：經(jīng)典的低停頓搜集器，絕大多數(shù)商用、延時敏感的服務(wù)在使用；

• G1：JDK 9默認(rèn)搜集器，堆內(nèi)存比較大（6G-8G以上）的時候表現(xiàn)出比較高吞吐量和短暫的停頓時間；

• ZGC：JDK 11中推出的一款低延遲垃圾回收器，目前處在實驗階段；

結(jié)合當(dāng)前服務(wù)的實際情況(堆大小，可維護(hù)性)，我們選擇ParNew CMS方案是比較合適的。

參數(shù)選擇的原則如下：

1）Meta區(qū)域的大小一定要指定，且MetaspaceSize和MaxMetaspaceSize大小應(yīng)設(shè)置一致，具體多大要結(jié)合線上實例的情況，通過jstat -gc可以獲取該服務(wù)線上實例的情況。

# jstat -gc 31247S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT37888.0?37888.0?0.0?32438.5?972800.0?403063.5?3145728.0?2700882.3?167320.0?152285.0?18856.0?16442.4?15189?597.209?65?70.447?667.655

可以看出MU在150M左右，

因此-XX:MetaspaceSize=256M?

-XX:MaxMetaspaceSize=256M是比較合理的。

2）Young區(qū)也不是越大越好。

當(dāng)堆大小一定時，Young區(qū)越大，Young GC的頻率一定越小，但Old區(qū)域就會變小，如果太小，稍微晉升一些對象就會觸發(fā)Full GC得不償失。

如果Young區(qū)過小，Young GC就會比較頻繁，這樣Old區(qū)就會比較大，單次Full GC的停頓就會比較大。因此Young區(qū)的大小需要結(jié)合服務(wù)情況，分幾種場景進(jìn)行比較，最終獲得最合適的配置。

基于以上原則，以下為4種參數(shù)組合：

1.ParNew CMS，Young區(qū)擴(kuò)大1倍

-Xms4096M -Xmx4096M -Xmn2048M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC-XX: CMSScavengeBeforeRemark

2.ParNew CMS，Young區(qū)擴(kuò)大1倍，

去除-XX: CMSScavengeBeforeRemark

（使用【-XX:CMSScavengeBeforeRemark】參數(shù)可以做到在重新標(biāo)記前先執(zhí)行一次新生代GC）。

因為老年代和年輕代之間的對象存在跨代引用，因此老年代進(jìn)行GC Roots追蹤時，同樣也會掃描年輕代，而如果能夠在重新標(biāo)記前先執(zhí)行一次新生代GC，那么就可以少掃描一些對象，重新標(biāo)記階段的性能也能因此提升。）

-Xms4096M -Xmx4096M -Xmn2048M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC

3.ParNew CMS，Young區(qū)擴(kuò)大0.5倍

-Xms4096M -Xmx4096M -Xmn1536M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC -XX: CMSScavengeBeforeRemark

4.ParNew CMS，Young區(qū)不變

-Xms4096M -Xmx4096M -Xmn1024M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC -XX: CMSScavengeBeforeRemark

下面，我們需要在壓測環(huán)境，對不同負(fù)載下4種方案的實際表現(xiàn)進(jìn)行比較，分析，驗證。

4.1 壓測環(huán)境驗證/分析

高負(fù)載場景(1100?QPS)GC表現(xiàn)

可以看出，在高負(fù)載場景，4種ParNew CMS的各項指標(biāo)表現(xiàn)均遠(yuǎn)好于Parrallel Scavenge Parrallel Old。其中：

• 方案4(Young區(qū)擴(kuò)大0.5倍)表現(xiàn)最佳，接口P95，P99延時相對當(dāng)前方案降低50%，F(xiàn)ull GC累積耗時減少88%， Young GC次數(shù)減少23%，Young GC累積耗時減少4%，Young區(qū)調(diào)大后，雖然次數(shù)減少了，但Young區(qū)大了，單次Young GC的耗時也大概率會上升，這是符合預(yù)期的。
  
  

• Young區(qū)擴(kuò)大1倍的兩種方案，即方案2和方案3，表現(xiàn)接近，接口P95，P99延時相對當(dāng)前方案降低40%，F(xiàn)ull GC累積耗時減少81%， Young GC次數(shù)減少43%，Young GC累積耗時減少17%，略遜于Young區(qū)擴(kuò)大0.5倍，總體表現(xiàn)不錯，這兩個方案進(jìn)行合并，不再區(qū)分。

Young區(qū)不變的方案在新方案里，表現(xiàn)最差，淘汰。所以在中負(fù)載場景，我們只需要對比方案2和方案4。

中負(fù)載場景(600?QPS)GC表現(xiàn)

可以看出，在中負(fù)載場景，2種ParNew CMS(方案2和方案4)的各項指標(biāo)表現(xiàn)也均遠(yuǎn)好于Parrallel Scavenge Parrallel Old。

• Young區(qū)擴(kuò)大1倍的方案表現(xiàn)最佳，接口P95，P99延時相對當(dāng)前方案降低32%，F(xiàn)ull GC累積耗時減少93%， Young GC次數(shù)減少42%，Young GC累積耗時減少44%；

• Young區(qū)擴(kuò)大0.5倍的方案稍遜一些。

綜合來看，兩個方案表現(xiàn)十分接近，原則上兩種方案都可以，只是Young區(qū)擴(kuò)大0.5倍的方案在業(yè)務(wù)高峰期的表現(xiàn)更佳，為盡量保證高峰期服務(wù)的穩(wěn)定和性能，目前更傾向于選擇ParNew CMS，Young區(qū)擴(kuò)大0.5倍方案。

4.2 灰度方案/分析

為保證覆蓋業(yè)務(wù)的高峰期，選擇周五、周六、周日分別從兩個機房隨機選擇一臺線上實例，線上實例的指標(biāo)符合預(yù)期后，再進(jìn)行全量升級。

目標(biāo)組? xx.xxx.60.6

采用方案2，即目標(biāo)方案

-Xms4096M -Xmx4096M -Xmn1536M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC -XX: CMSScavengeBeforeRemark

對照組1? xx.xxx.15.215

采用原始方案

-Xms4096M -Xmx4096M -Xmn1024M-XX:PermSize=512M-XX:MaxPermSize=512M

對照組2? xx.xxx.40.87

采用方案4，即候選目標(biāo)方案

-Xms4096M -Xmx4096M -Xmn2048M-XX:MetaspaceSize=256M-XX:MaxMetaspaceSize=256M-XX: UseParNewGC-XX: UseConcMarkSweepGC -XX: CMSScavengeBeforeRemark

灰度3臺機器。

我們先分析下Young GC相關(guān)指標(biāo)：

Young GC次數(shù)

Young GC累計耗時

Young GC單次耗時

可以看出，與原始方案相比，目標(biāo)方案的YGC次數(shù)減少50%，累積耗時減少47%，吞吐量提升的同時，服務(wù)停頓的頻率大大降低，而代價是單次Young GC的耗時增長3ms，收益是非常高的。

對照方案2即Young區(qū)2G的方案整體表現(xiàn)稍遜與目標(biāo)方案，再分析Full GC指標(biāo)。

老年代內(nèi)存增長情況

Full GC次數(shù)

Full GC累計/單次耗時

與原始方案相比，使用目標(biāo)方案時，老年代增長的速度要緩慢很多，基本在觀測周期內(nèi)Full GC發(fā)生的次數(shù)從155次減少至27次，減少82%，停頓時間均值從399ms減少至60ms，減少85%，毛刺也非常少。

對照方案2即Young區(qū)2G的方案整體表現(xiàn)遜于目標(biāo)方案。到這里，可以看出，目標(biāo)方案從各個維度均遠(yuǎn)優(yōu)于原始方案，調(diào)優(yōu)目標(biāo)也基本達(dá)成。

但細(xì)心的同學(xué)會發(fā)現(xiàn)，目標(biāo)方案相對原始方案，"Full GC"(實際上是CMS Background GC)耗時更加平穩(wěn)，但每個若干次"Full GC"后會有一個耗時很高的毛刺出現(xiàn)，這意味這個用戶請求在這個時刻會停頓2-3s，能否進(jìn)一步優(yōu)化，給用戶一個更加極致的體驗?zāi)兀?/p>

4.3 再次優(yōu)化

這里首先要分析這現(xiàn)象背后的邏輯。

對于CMS搜集器，采用的搜集算法為Mark-Sweep-[Compact]。

CMS搜集器GC的種類：

CMS Background GC

這種GC是CMS最常見的一類，是周期性的，由JVM的常駐線程定時掃描老年代的使用率，當(dāng)使用率超過閾值時觸發(fā)，采用的是Mark-Sweep方式，由于沒有Compact這種耗時操作，且可以與用戶進(jìn)程并行，所以CMS的停頓會比較低，GC日志中出現(xiàn)GC (CMS Initial Mark)字樣就代表發(fā)生了一次CMS Background GC。

Background GC由于采用的是Mark-Sweep，會導(dǎo)致老年代內(nèi)存碎片，這也是CMS最大的弱點。

CMS Foreground GC

這種GC是CMS搜集器里真正意義上的Full GC，采用Serial Old或Parralel Old進(jìn)行收集，出現(xiàn)的頻率就較低，當(dāng)往往出現(xiàn)后就會造成較大的停頓。

觸發(fā)CMS Foreground GC的場景有很多，場景的如下：

• System.gc()；

• jmap -histo:live pid；

• 元數(shù)據(jù)區(qū)域空間不足；

• 晉升失敗，GC日志中的標(biāo)志為ParNew(promotion failed)；

• 并發(fā)模式失敗，GC日志中的標(biāo)志為councurrent mode failure字樣。

不難推斷，目標(biāo)方案中的毛刺是晉升失敗或并發(fā)模式失敗造成的，由于線上沒有開啟打印gc日志，但也無妨，因為這兩種場景的根因是一致的，就是若干次CMS Backgroud GC后造成的老年代內(nèi)存碎片。

我們只需要盡可能減少由于老年代碎片觸發(fā)晉升失敗、并發(fā)模式失敗即可。

CMS Background GC由JVM的常駐線程定時掃描老年代的使用率，當(dāng)使用率超過閾值時觸發(fā)，該閾值由-XX:CMSInitiatingOccupancyFraction;?

-XX: UseCMSInitiatingOccupancyOnly兩個參數(shù)控制，不設(shè)置，默認(rèn)首次為92%，后續(xù)會根據(jù)歷史情況進(jìn)行預(yù)測，動態(tài)調(diào)整。

如果我們固定閾值的大小，將該閾值設(shè)置為一個相對合理的值，既不使GC過于頻繁，又可以降低晉升失敗或并發(fā)模式失敗的概率，就可以大大緩解毛刺產(chǎn)生的頻率。

目標(biāo)方案的堆分布如下：

• Young區(qū) 1.5G

• Old區(qū) 2.5G

• Old區(qū)常駐對象 約400M

按經(jīng)驗數(shù)據(jù)，75%，80%是比較折中的，因此我們選擇-XX:CMSInitiatingOccupancyFraction=75 -

XX: UseCMSInitiatingOccupancyOnly進(jìn)行灰度觀察（我們也對80%的場景做了對照實驗，75%優(yōu)于80%）。

最終目標(biāo)方案的配置為：

-Xms4096M -Xmx4096M -Xmn1536M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX: UseParNewGC -XX: UseConcMarkSweepGC -XX: CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=75 -XX: UseCMSInitiatingOccupancyOnly

如上配置，灰度 xx.xxx.60.6 一臺機器；

從再次優(yōu)化的結(jié)果上看，CMS Foreground GC引起的毛刺基本消失，符合預(yù)期。

因此，視頻服務(wù)最終目標(biāo)方案的配置為；

-Xms4096M?-Xmx4096M?-Xmn1536M?-XX:MetaspaceSize=256M?-XX:MaxMetaspaceSize=256M?-XX: UseParNewGC?-XX: UseConcMarkSweepGC?-XX: CMSScavengeBeforeRemark?-XX:CMSInitiatingOccupancyFraction=75?-XX: UseCMSInitiatingOccupancyOnly

五、結(jié)果驗收

灰度持續(xù)7天左右，覆蓋工作日與周末，結(jié)果符合預(yù)期，因此符合在線上開啟全量的條件，下面對全量后的結(jié)果進(jìn)行評估。

Young GC次數(shù)

Young GC累計耗時

單次Young GC耗時

從Young GC指標(biāo)上看，調(diào)整后Young GC次數(shù)平均減少30%，Young GC累積耗時平均減少17%，Young GC單次耗時平均增加約7ms，Young GC的表現(xiàn)符合預(yù)期。

除了技術(shù)手段，我們也在業(yè)務(wù)上做了一些優(yōu)化，調(diào)優(yōu)前實例的Young GC會出現(xiàn)明顯的、不規(guī)律的（定時任務(wù)不一定分配到當(dāng)前實例）毛刺，這里是業(yè)務(wù)上的一個定時任務(wù)，會加載大量數(shù)據(jù)，調(diào)優(yōu)過程中將該任務(wù)進(jìn)行分片，分?jǐn)偟蕉鄠€實例上，進(jìn)而使Young GC更加平滑。

Full GC單次/累積耗時

從"Full GC"的指標(biāo)上看，"Full GC"的頻率、停頓極大減少，可以說基本上沒有真正意義上的Full GC了。

核心接口-A (下游依賴較多) P99響應(yīng)時間，減少19%（從 3457 ms下降至 2817 ms）；

核心接口-B (下游依賴中等)? P99響應(yīng)時間，減少41%（從 1647ms下降至 973ms）；

核心接口-C (下游依賴最少) P99響應(yīng)時間，減少80%（從 628ms下降至 127ms）；

綜合來看，整個結(jié)果是超出預(yù)期的。Young GC表現(xiàn)與設(shè)定的目標(biāo)非常吻合，基本上沒有真正意義上的Full GC，接口P99的優(yōu)化效果取決于下游依賴的多少，依賴越少，效果越明顯。

六、寫在最后

由于GC算法復(fù)雜，影響GC性能的參數(shù)眾多，并且具體參數(shù)的設(shè)置又取決于服務(wù)的特點，這些因素都很大程度增加了JVM調(diào)優(yōu)的難度。

本文結(jié)合視頻服務(wù)的調(diào)優(yōu)經(jīng)驗，著重介紹調(diào)優(yōu)的思路和落地過程，同時總結(jié)出一些通用的調(diào)優(yōu)流程，希望能給大家提供一些參考。