每秒 10 萬並發的 BI 系統如何頻繁發生 Young GC？

作者 |救火隊隊長

責編 | 伍杏玲

本周我們的一個重點就是給大家再次強調JVM頻繁GC對系統性能的危害性。

因此在分析完JVM發生GC的場景以及原理，以及梳理清楚各種GC名詞的概念和觸發時機之後，我們就可以來用兩個之前我們線上系統真實的案例來給大家再次在腦海中強化一下頻繁GC帶來的性能問題。

什麼是 BI 系統？

先給大家說一下我們線上一個真實的生產系統，是一個服務於百萬級商家的BI系統。

這個所謂BI系統，很多開發業務系統的同學可能沒接觸過，所以簡單介紹一下背景。

簡單來說，比如你是一個平台，然後有數十萬甚至上百萬的商家在你的平台上做生意，會使用你的這個平台系統。

此時一定會產生大量的數據，基於這些數據我們需要為商家提供一些數據報表。比如：每個商家每天有多少訪客？有多少交易？付費轉化率是多少？

當然實際情況會比這個簡單幾句話複雜很多，這裡就是簡單說一下它的概念。

因此就需要一套BI系統，所謂BI，英文全稱是「Business Intelligence」，也就是「商業智能」，聽起來是不是特別的高大上？

其實也別想的太高大上了，說白了，就是把一些商家平時日常經營的數據收集起來進行分析，然後把各種數據報表展示給商家的一套系統。

所謂「商務智能」，指的就是給你看一些數據報表，然後讓你平時能夠更好的了解自己的經營狀況，然後讓老闆「智能」的去調整經營策略，提升業績。

所以類似這樣的一個BI系統，大致的運行邏輯如下所示，首先從我們提供給商家日常使用的一個平台上會採集出來很多商家日常經營的數據。

如下圖所示：

接著就可以對這些經營數據依託各種大數據計算平台，比如Hadoop、Spark、Flink等技術進行海量數據的計算，計算出來各種各樣的數據報表。

如下圖所示：

然後我們需要將計算好的各種數據分析報表都放入一些存儲中，比如MySQL、ElastciSearch、HBase都可以存放類似的數據。

如下圖所示：

最後一步，就是基於MySQL、HBase、ElasticSearch中存儲的數據報表，基於Java開發出來一個BI系統。

然後通過這個系統，把各種存儲好的數據暴露給前端，允許前端基於各種條件對存儲好的數據進行複雜的篩選和分析。

如下圖所示：

剛開始上線系統時候的部署架構

我們在這裡重點作為案例分析的就是上述場景中的BI系統，其他環節都跟大數據相關的技術是有關聯的，暫時先不涉及，未來有機會可以給大家出更多的課程來闡述那些技術。

剛開始，這個BI系統使用的商家是不多的。

因為大家要知道，即使在一個龐大的互聯網大廠里，雖然大廠本身積累了大量的商家，但是你要是針對他們上線一個付費的產品，剛開始未必所有人都買賬。所以一開始系統上線大概就少數商家在使用，比如就幾千個商家。

因此剛開始系統部署的非常簡單，就是用幾台機器來部署了上述的BI系統，機器都是普通的4核8G的配置。

然後在這個配置之下，一般來說給堆內存中的新生代分配的內存都在1.5G左右，Eden區大概也就1G左右的空間。

如下圖所示：

技術痛點：實時自動刷新報表 大數據量報表

其實剛開始，在少數商家的量級之下，這個系統是沒多大問題的，運行的非常良好，但問題就出在使用系統的商家數量開始暴漲的時候。

突然使用系統的商家開始越來越多，比如給大家舉個例子，當商家的數量級達到幾萬的時候。

此時要給大家說明一個此類BI系統的特點，就是在BI系統中有一種數據報表，他是支持前端頁面有一個JS腳本，自動每隔幾秒鐘就發送請求到後台刷新一下數據的。

這種報表稱之為「實時數據報表」，如下圖所示：

那麼大家可以設想一下，假設僅僅就幾萬商家作為你的系統用戶，很可能同一時間打開那個實時報表的商家就有幾千個

然後每個商家打開實時報表之後，前端頁面都會每隔幾秒鐘發送請求到後台來載入最新數據。

這時基本上會出現你的BI系統部署的每台機器每秒的請求會達到幾百個，這裡就假設每秒500個請求。

然後每個請求會載入出來一張報表需要的大量數據，因為BI系統可能還需要針對那些數據進行內存中的現場計算加工一下，才能返回給前端頁面展示。

根據我們之前的測算，每個請求大概需要載入出來100kb的數據進行計算，因此每秒500個請求，就需要載入出來50MB的數據到內存中進行計算。

如下圖所示：

沒什麼大影響的頻繁Young GC

其實大家都已經發現上述系統的問題了，在上述系統運行模型下，基本上每秒會載入50MB的數據到Eden區中。

也就是說，只要區區200s，也就是3分鐘左右的時間，就會迅速填滿Eden區，然後觸發一次Young GC對新生代進行垃圾回收。

當然1G左右的Eden進行Young GC其實速度相對是比較快的，可能也就幾十ms的時間就可以搞定了。

所以之前也分析過，這其實對系統性能影響並不大。而且上述BI系統場景下，基本上每次Young GC後存活對象可能就幾十MB，甚至是幾MB。

所以如果僅僅只是這樣的話，大家可能會看到如下場景，BI系統運行幾分鐘過後，就會突然卡頓個10ms，但是對終端用戶和系統性能幾乎是沒有影響的。

如下圖：

提升機器配置：運用大內存機器

針對這樣的一套系統，後來隨著越來越多的商家來使用，並發壓力越來越大，甚至高峰期會有每秒10萬的並發壓力。

如果還是用4核8G的機器來支撐，那麼可能需要部署上百台機器來抗住每秒10萬的高並發壓力。

所以一般針對這種情況，我們會提升機器的配置。

本身BI系統就是非常吃內存的系統，所以我們將部署的機器全面提升到了16核32G的高配置機器上去。每台機器可以抗個每秒幾千請求，此時只要部署二三十台機器就可以了。

但是此時問題就來了，如果要是用大內存機器的話，那麼新生代至少會分配到20G的大內存，Eden區也會佔據16G以上的內存空間。

如下圖所示：

此時每秒幾千請求的話，每秒大概會載入到內存中幾百MB的數據，那麼大概可能幾十秒，甚至1分鐘左右就會填滿Eden區，就需要執行Young GC了。

此時Young GC要回收那麼大的內存，速度會慢很多，也許此時就會導致系統卡頓個幾百毫秒，或者1秒鐘。

如下圖所示：

那麼你要是系統卡頓時間過長，必然會導致瞬間很多請求積壓排隊，嚴重的時候會導致線上系統時不時出現前端請求超時的問題，就是前端請求之後發現一兩秒後還沒返回就超時報錯了。

用G1來優化大內存機器的Young GC性能

所以當時對這個系統的一個優化，就是採用G1垃圾回收器來應對大內存的Young GC過慢的問題。

（PS：關於G1回收器，我們此前已經通過一步一圖的方式，詳細闡述了其工作原理，如果忘記了的同學，可以回看一下）

可以對G1設置一個預期的GC停頓時間，比如100ms，讓G1保證每次Young GC的時候最多停頓100ms，避免影響終端用戶的使用。

此時效果是非常顯著的，G1會自動控制好在每次Young GC的時候就回收一部分Region，確保GC停頓時間控制在100ms以內。

這樣的話，也許Young GC的頻率會更高一些，但是每次停頓時間很小，這樣對系統影響就不大了。

本文總結

本文用一個案例，其實就想說明一個問題，通常Young GC哪怕發生的頻繁一些，其實一般都對系統造成不了太大的影響。

只有在你機器內存特別大的時候，才需要注意Young GC也可能會導致比較長時間的停頓，此時針對大內存機器通常建議採用G1垃圾回收器。

看到這裡，給大家留一個小思考題，去想辦法看看自己線上系統：

多長時間發生一次Young GC？

Young GC耗時多久？

你覺得它對你的系統影響大嗎？

作者簡介：救火隊隊長，阿里資深技術專家。本文來源於公眾號狸貓技術窩的專欄：《從零開始帶你成為JVM實戰高手》試讀文章。

【END】

9.5-7日 AI 開發大會（AI ProCon），7位出品人集結國內外60 技術大咖，探秘9大核心技術，深剖行業痛點，亞馬遜首席科學家李沐還將親授「深度學習集訓營」，助力開發者實現技術躍遷。

熱 文推 薦

你點的每個「在看」，我都認真當成了喜歡

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！