使用G1 GC時HBase為什么性能下降了近20%

編者按：筆者在 HBase 業(yè)務場景中嘗試將 JDK 從 8 升級到 11，使用 G1 GC 作為垃圾回收器，但是性能下降 20%。到底是什么導致了性能衰退？又該如何定位解決？本文介紹如果通過使用 JFR、火焰圖等工具確定問題，最后通過版本逐一驗證找到了引起性能問題的代碼。在畢昇 JDK 中率先修復問題最后將修復推送到上游社區(qū)中。希望通過本文的介紹讓讀者了解到如何解決大版本升級中遇到的性能問題；同時也提醒 Java 開發(fā)者要正確地使用參數(shù)（使用前要理解參數(shù)的含義）。

HBase 從 2.3.x 開始正式默認的支持 JDK 11，HBase 對于 JDK 11 的支持指的是 HBase 本身可以通過 JDK 11 的編譯、同時相關的測試用例全部通過。由于 HBase 依賴 Hadoop 和 Zookeeper，而目前最新的 Hadoop 和 Zookeeper 尚未支持 JDK 11，所以 HBase 中仍然有一個 jira 來關注 JDK 11 支持的問題，具體參考：https://issues.apache.org/jira/browse/HBASE-22972。

G1 GC 從 JDK 9 以后就成為默認的 GC，而且 HBase 在新的版本中也采用 G1 GC，對于 HBase 是否可以在生產(chǎn)環(huán)境中使用 JDK 11？筆者嘗試使用 JDK 11 來運行新的 HBase，驗證 JDK 11 是否比 JDK 8 有優(yōu)勢。

環(huán)境介紹

驗證的方式非常簡單，搭建一個 3 節(jié)點的 HBase 集群，安裝 HBase，采用的版本為 2.3.2，關于 HBase 環(huán)境搭建可以參考官網(wǎng)。

另外為了驗證，使用一個額外的客戶端機器，通過 HBase 自帶的 PerformanceEvaluation 工具（簡稱 PE）來驗證 HBase 讀、寫性能。PE 支持隨機的讀、寫、掃描，順序讀、寫、掃描等。

例如一個簡單的隨機寫命令如下：

hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10000 --valueSize=8000 randomWrite 5

該命令的含義是：創(chuàng)建 5 個客戶端，并且執(zhí)行持續(xù)的寫入測試。每個客戶端每次寫入 8000 字節(jié)，共寫入 10000 行。

PE 使用起來非常簡單，是 HBase 壓測中非常流行的工具，關于 PE 更多的用法可以參考相關手冊。

本次測試為了驗證讀寫性能，采用如下配置：

org.apache.hadoop.hbase.PerformanceEvaluation --writeToWAL=true --nomapred --size=256 --table=Test1 --inmemoryCompaction=BASIC --presplit=50 --compress=SNAPPY sequentialWrite 120

JDK 采用 JDK 8u222 和 JDK 11.0.8 分別進行測試，當切換 JDK 時，客戶端和 3 臺 HBase 服務器統(tǒng)一切換。JDK 的運行參數(shù)為：

-XX：+PrintGCDetails -XX：+UseG1GC -XX:MaxGCPauseMillis=100 -XX：-ResizePLAB

注意：這里禁止 ResizePLAB 是業(yè)務根據(jù) HBase 優(yōu)化資料設置。

測試結(jié)果：JDK 11 性能下降

通過 PE 進行測試，運行結(jié)束有 TPS 數(shù)據(jù)，表示性能。

在相同的硬件環(huán)境、相同的 HBase，僅僅使用不同的 JDK 來運行。同時為了保證結(jié)果的準確性，多次運行，取平均值。測試結(jié)果如下：

從表中可以快速地計算得到吞吐量下降，運行時間增加。

結(jié)論：使用 G1 GC，JDK 11 相對于 JDK 8 來說性能明顯下降。

原因分析

從 JDK 8 到 JDK 11， G1 GC 做了非常多的優(yōu)化用于提高性能。為什么 JDK 11 對于應用者來說更不友好？簡單的總結(jié)一下從 JDK 8 到 JDK 11 做的一些比較大的設計變化，如下表所示：

優(yōu)化點描述

IHOP 啟發(fā)式設置IHOP 用于控制并發(fā)標記的啟動時機，在 JDK 9 中引入該優(yōu)化，根據(jù)應用運行的情況，計算 IHOP 的值，確保在內(nèi)存耗盡之前啟動并發(fā)標記。對于性能和運行時間理論上都是正優(yōu)化，特殊情況下可能會導致性能下降

Full GC 的并行話在 JDK10 中將 Full GC 從串行實現(xiàn)優(yōu)化為并行實現(xiàn)，該優(yōu)化不會產(chǎn)生負面影響

動態(tài)線程調(diào)整根據(jù) GC 工作線程的負載情況，引入動態(tài)的線程數(shù)來處理任務。該優(yōu)化會帶來正效果，注意不是 GC 工作線程數(shù)目越多 GC 的效果越好（GC 會涉及到多線程的任務竊取和同步機制，過多的線程會導致性能下降）

引用集的重構(gòu)引用集處理優(yōu)化，設置處理大小、將并行修改為并發(fā)等

統(tǒng)一 JDK 8 和 JDK 11 的參數(shù)，驗證效果

由于 JDK 11 和 JDK 8 實現(xiàn)變化很多，部分功能完全不同，但是這些變化的功能一般都有參數(shù)控制，一種有效的嘗試：梳理 JDK 8 和 JDK 11 關于 G1 的參數(shù)，將它們設置為相同的值，比如關閉 IHOP 的自適應，關閉線程調(diào)整等。這里簡單的給出 JDK 8 和 JDK 11 不同參數(shù)的比較，如下圖所示：

將兩者參數(shù)都設置為和 JDK 8 一樣的值，重新驗證測試，結(jié)果不變，JDK 11 性能仍然下降。

GC 日志分析，確定 JDK 11 性能下降點

對于 JDK 8 和 JDK 11 同時配置日志收集功能，重新測試，獲得 GC 日志。通過 GC 日志分析，我們發(fā)現(xiàn)差異主要在 G1 young gc 的 object copy 階段（耗時基本在這），JDK 11 的 Young GC 耗時大概 200ms，JDK 8 的 Young GC 耗時大概 100ms，兩者設置的目標停頓時間都是 100ms。

JDK 11 中 GC 日志片段：

JDK 8 中 GC 日志片段：

我們對整個日志做了統(tǒng)計，有以下發(fā)現(xiàn)：

并發(fā)標記時機不同，混合回收的時機也不同；

單次 GC 中對象復制的耗時不同，JDK 11 明顯更長；

總體 GC 次數(shù) JDK 11 的更多，包括了并發(fā)標記的停頓次數(shù)；

總體 GC 的耗時 JDK 11 更多。

針對 Young GC 的性能劣化，我們重點關注測試了和 Young GC 相關的參數(shù)，例如：調(diào)整 UseDynamicNumberOfGCThreads、G1UseAdaptiveIHOP 、GCTimeRatio 均沒有效果。

下面我們嘗試使用不同的工具來進一步定位到底哪里出了問題。

JFR 分析-確認日志分析結(jié)果

畢昇 JDK 11 和畢昇 JDK 8 都引入了 JFR，JFR 作為 JVM 中問題定位的新貴，我們也在該案例進行了嘗試，關于 JFR 的原理和使用，參考本系列的技術文章：Java Flight Recorder - 事件機制詳解

JDK 11 總體信息

JDK 8 中通過 JFR 收集信息。

JDK 8 總體信息

JFR 的結(jié)論和我們前面分析的結(jié)論一致，JDK 11 中中斷比例明顯高于 JDK 8。

JDK 11 中垃圾回收發(fā)生的情況

JDK 8 中垃圾回收發(fā)生的情況

從圖中可以看到在 JDK 11 中應用消耗內(nèi)存的速度更快（曲線速率更為陡峭），根據(jù)垃圾回收的原理，內(nèi)存的消耗和分配相關。

JDK 11 中 VM 操作

JDK 8 中 VM 操作

通過 JFR 整體的分析，得到的結(jié)論和我們前面的一致，確定了 Young GC 可能存在問題，但是沒有更多的信息。

火焰圖-發(fā)現(xiàn)熱點

為了進一步的追蹤 Young GC 里面到底發(fā)生了什么導致對象賦值更為耗時，我們使用 Async-perf 進行了熱點采集。關于火焰圖的使用參考本系列的技術文章：使用 perf 解決 JDK8 小版本升級后性能下降的問題［1］

JDK 11 的火焰圖

JDK 11 GC 部分火焰圖

圖片 JDK 8 的火焰圖

JDK 8 GC 部分火焰圖

通過分析火焰圖，并比較 JDK 8 和 JDK 11 的差異，可以得到：

在 JDK 11 中，耗時主要在：

G1ParEvacuateFollowersClosure：：do_void（）

G1RemSet：：scan_rem_set

在 JDK 8 中，耗時主要在：

G1ParEvacuateFollowersClosure：：do_void（）

更一步，我們對 JDK 11 里面新出現(xiàn)的 scan_rem_set（） 進行更進一步分析，發(fā)現(xiàn)該函數(shù)僅僅和引用集相關，通過修改 RSet 相關參數(shù)（修改 G1ConcRefinementGreenZone ），將 RSet的處理盡可能地從Young GC的操作中移除。火焰圖中參數(shù)不再成為熱點，但是 JDK 11 仍然性能下降。

比較 JDK 8 和 JDK 11 中 G1ParEvacuateFollowersClosure：：do_void（） 中的不同，除了數(shù)組處理外其他的基本沒有變化，我們將 JDK 11 此處的代碼修改和 JDK 8 完全一樣，但是性能仍然下降。

結(jié)論：雖然 G1ParEvacuateFollowersClosure：：do_void（） 是性能下降的觸發(fā)點，但是此處并不是問題的根因，應該是其他的原因造成了該函數(shù)調(diào)用次數(shù)增加或者耗時增加。

逐個版本驗證-最終確定問題

我們分析了所有可能的情況，仍然無法快速找到問題的根源，只能使用最笨的辦法，逐個版本來驗證從哪個版本開始性能下降。

在大量的驗證中，對于 JDK 9、JDK 10，以及小版本等都重新做了構(gòu)建（關于 JDK 的構(gòu)建可以參考官網(wǎng)），我們發(fā)現(xiàn) JDK 9-B74 和 JDK 9-B73 有一個明顯的區(qū)別。為此我們分析了 JDK 9-B73 合入的代碼。發(fā)現(xiàn)該代碼和 PLAB 的設置相關，為此梳理了所有 PLAB 相關的變動：

B66 版本為了解決 PLAB size 獲取不對的問題（根據(jù) GC 線程數(shù)量動態(tài)調(diào)整，但是開啟 UseDynamicNumberOfGCThreads 后該值有問題，默認是關閉）修復了 bug。具體見 jira：Determining the desired PLAB size adjusts to the the number of threads at the wrong place［2］

B74 發(fā)現(xiàn)有問題（desired_plab_sz 可能會有相除截斷問題和沒有對齊的問題），重新修改，具體見 8079555： REDO - Determining the desired PLAB size adjusts to the the number of threads at the wrong place［3］

B115 中發(fā)現(xiàn) B74 的修改，動態(tài)調(diào)整 PLAB大小后，會導致很多情況 PLAB過?。ù蟾啪褪遣蛔?PLAB，走了直接分配），頻繁的話會導致性能大幅下降，又做了修復 Net PLAB size is clipped to max PLAB size as a whole， not on a per thread basis［4］

重新修改了代碼，打印 PLAB 的大小。對比后發(fā)現(xiàn) desired_plab_sz 大小，在性能正常的版本中該值為 1024 或者 4096（分別是 YoungPLAB 和 OLDPLAB），在性能下降的版本中該值為 258。由此確認 desired_plab_sz 不正確的計算導致了性能下降。

PALB 為什么會引起性能下降？

PLAB 是 GC 工作線程在并行復制內(nèi)存時使用的緩存，用于減少多個并行線程在內(nèi)存分配時的鎖競爭。PLAB 的大小直接影響 GC 工作線程的效率。

在 GC 引入動態(tài)線程調(diào)整的功能時，將原來 PLABSize 的大小作為多個線程的總體 PLAB 的大小，將 PLAB 重新計算，如下面代碼片段：

其中 desired_plab_sz 主要來自 YoungPLABSize 和 OldPLABSIze 的設置。所以這樣的代碼修改改變了 YoungPLABSize、OldPLABSize 參數(shù)的語義。

另外，在本例中，通過參數(shù)顯式地禁止了 ResizePLAB 是觸發(fā)該問題的必要條件，當打開 ResizePLAB 后，PLAB 會根據(jù) GC 工作線程晉升對象的大小和速率來逐步調(diào)整 PLAB 的大小。

注意，眾多資料說明：禁止 ResziePLAB 是為了防止 GC 工作線程的同步，這個說法是不正確的，PLAB 的調(diào)整耗時非常的小。PLAB 是 JVM 根據(jù) GC 工作線程使用內(nèi)存的情況，根據(jù)數(shù)學模型來調(diào)整大小，由于模型的誤差，可能導致 PLAB 的大小調(diào)整不一定有人工調(diào)參效果好。如果你沒有對 YoungPLABSize、OldPLABSize 進行調(diào)優(yōu)，并不建議禁止 ResizePLAB。在 HBase 測試中，當打開 ResizePLAB 后 JDK 8 和 JDK 11 性能基本相同，也從側(cè)面說明了該參數(shù)的使用情況。

解決方法&修復方法

由于該問題是 JDK 9 引入，在 JDK 9， JDK 10， JDK 11， JDK 12， JDK 13， JDK 14， JDK 15， JDK 16 都會存在性能下降的問題。

我們對該問題進行了修正，并提交到社區(qū)，具體見 Jira：https://bugs.openjdk.java.net/browse/JDK-8257145［5］；代碼見：https://github.com/openjdk/jdk/pull/1474［6］；該問題在 JDK 17 中被修復。

同時該問題在畢昇 JDK 所有版本中第一時間得到解決。

當然對于短時間內(nèi)無法切換 JDK 的同學，遇到這個問題，該如何解決？難道要等到 JDK 17？一個臨時的方法是顯式地設置 YoungPLABSize 和 OldPLABSize 的值。YoungPLABSize 設置為 YoungPLABSize* ParallelGCThreads，其中 ParallelGCThreads 為 GC 并行線程數(shù)。例如 YoungPLABSize 原來為 1024，ParallelGCThreads 為 8，在 JDK 9~16，將 YoungPLABSize 設置為 8192 即可。

其中參數(shù) ParallelGCThreads 的計算方法為：沒有設置該參數(shù)時，當 CPU 個數(shù)小于等于 8， ParallelGCThreads 等于 CPU 個數(shù)，當 CPU 個數(shù)大于 8，ParallelGCThreads 等于 CPU 個數(shù)的 5/8）。

小結(jié)

本文分享了針對 JDK 升級后性能下降的解決方法。Java 開發(fā)人員如果遇到此類問題，可以按照下面的步驟嘗試自行解決：

對齊不同 JDK 版本的參數(shù)，確保參數(shù)相同，看是否可以快速重現(xiàn)；

分析 GC 日志，確定是否由 GC 引起。如果是，建議將所有的參數(shù)重新驗證，包括移除原來的參數(shù)。本例中一個最大的失誤是，在分析過程中沒有將原來業(yè)務提供的參數(shù) ResizePLAB 移除重新測試，浪費了很多時間。如果執(zhí)行該步驟后，定位問題可能可以節(jié)約很多時間；

使用一些工具，比如 JFR、NMT、火焰圖等。本例中嘗試使用這些工具，雖然無果，但基本上確認了問題點；

最后的最后，如果還是沒有解決，請聯(lián)系畢昇 JDK 社區(qū)（點擊原文進入社區(qū)）。畢昇 JDK 社區(qū)每雙周周二舉行技術例會，同時有一個技術交流群討論 GCC、LLVM 和 JDK 等相關編譯技術，感興趣的同學可以添加如下微信小助手入群。

責任編輯：haq