9.億級流量電商系統JVM模型引數預估方案

盛開的太陽 發表於 2021-10-14
JVM

1. 需求分析

大促在即,擁有億級流量的電商平臺開發了一個訂單系統,我們應該如何來預估其併發量?如何根據併發量來合理配置JVM引數呢?

假設,現在有一個場景,一個電商平臺,比如京東,需要承擔每天上億的流量。現在開發了一個訂單系統,那麼這個訂單系統每秒的併發量是多少呢?我們應該如何分配其記憶體空間呢?先來分析一下

9.億級流量電商系統JVM模型引數預估方案

每日億級流量,平均一個使用者點選量在20-30左右,通過這個計算出日活使用者數約1億/20=500萬, 看的人多,買的人少,通常下單率不超過10%,我們按照留存率10%來計算,日均訂單約50萬單。這是分兩種情況:

  • 一種是普通流量,非特殊節假日,通常早上、中午、晚上非工作時間有1個小時的時間集中購買。我們按照早上1小時,中午1小時,晚上1小時來計算,也就是3小時。這樣平均到每秒就是50萬/3/3600=46, 也就是及時併發,通常我們的服務都是一個叢集,有好幾臺伺服器承受著幾十併發,應該不成問題。
  • 另一種是大促流量,比如雙十一,基本流量都集中在雙十一當天的投幾分鐘。這時每秒的併發量大概在50萬/10/60=866,平均每秒併發量不到1000。這時服務叢集有3臺伺服器,沒太伺服器承受的壓力是400單/s。

2. 常規方案及問題暴露

對於這每秒400但會產生多大的物件呢?

9.億級流量電商系統JVM模型引數預估方案

我們假設訂單物件的大小是1kb,實際上訂單物件的大小和訂單物件中的欄位有關係,我們假設是1kb。每秒400單,也就是會產生400kb的訂單物件。下單還涉及到其他物件,比如庫存,優惠券,積分等等,我們將物件擴大20倍, 大約是(400kb*20)/秒. 可能同時還有其他操作,比如查詢訂單的操作,我們再講其擴大10倍,大約是80M,也就是每秒產生約80M的物件,這些物件在1s後都會變為垃圾。

對於一臺4核8G的伺服器來說,通常我們不設定JVM引數,也可能會根據物理機的8G記憶體來設定JVM引數。如果根據JVM引數來設定引數如何設定呢?

之前說過開啟逃逸分析會將物件分配到棧上,我們這裡計算分析的時候暫且忽略逃逸分析分配到棧上的物件,因為這部分物件相對來說比較少。下面我們來驗證上面的預估演算法是否準確,會有什麼樣的問題呢?

物理機有8G,分給os作業系統3G,分給JVM5G,然後JVM中給堆分配3G,後設資料空間分配512M,執行緒棧分配1M等等。這是估算,不夠精細,到底分配這麼多空間夠不夠呢,會不會浪費呢?會產生什麼樣的問題呢?

設定jvm引數大致如下:
  
-Xms3072M -Xmx3072M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M 

這樣設定到底行不行呢?有沒有問題呢?我們來看看執行時資料區:

9.億級流量電商系統JVM模型引數預估方案

根據計算

  • 整個堆空間3G
    • Eden區800M
    • s1/s2各100M
  • 方法區512M
  • 一個執行緒1M

按照這個模型來分析,得到如下結果:

9.億級流量電商系統JVM模型引數預估方案
  1. 大促期間1s產生80M的物件資料。我們知道物件資料都是放在Eden園區,Eden園區一共800M,那麼大約10s就放滿了,放滿了就會觸發Minor GC
  2. 觸發Minor GC的期間,會Stop The World暫停業務執行緒。在第10s觸發MinorGC的時候,前9s的720M資料都已經變成垃圾了,會被回收掉,最後1s的80M資料由於還有物件引用,只是暫停了業務執行緒,因此不是垃圾,不能被回收。會被放入S1區。
  3. 在Survivor區有一個物件動態年齡判斷機制。什麼是物件動態年齡判斷機制呢?

當前放物件的Survivor區域裡(其中一塊區域,放物件的那塊s區),一批物件的總大小大於這塊Survivor區域記憶體大小的50%(-XX:TargetSurvivorRatio可以指定),那麼此時大於等於這批物件年齡最大值的物件,就可以直接進入老年代了,

例如:Survivor區域裡現在有一批物件,年齡1+年齡2+年齡n的多個年齡物件總和超過了Survivor區域的50%,此時就會把年齡n(含)以上的物件都放入老年代。這個規則其實是希望那些可能是長期存活的物件,儘早進入老年代。

物件動態年齡判斷機制一般是在minor gc之後觸發的。

​ 也就是說當在Survivor區經過幾代的回收以後,如果物件總和大於Survivor區域的一半,則會直接放入到老年代。Survivor是100M,第10s的物件是80M,大於100M,會直接將這個物件放入到老年代。

9.億級流量電商系統JVM模型引數預估方案
  1. 老年代一共有2G空間,2G空間執行多少次會滿呢?2G/80M=25次,也就是發生25次(25秒)Minor GC就會觸發一次Full GC。這個頻率就太高了,通常應該要很少觸發Full GC,起碼也得1個小時觸發一次。而觸發的原因是因為垃圾物件(這些物件1s後都變成垃圾了),這樣肯定是不行的。我們需要優化JVM引數。

3. JVM優化

有問題有就解決問題。問題的根本原因是老年代發生了Full GC,為什麼會發生Full GC呢?

之所以80M物件會放到了老年代是因為每秒產生的資料 大於 Survivor區空間的一半。所以,我們可以調整Survivor區大小。通常我們不會修改預設的Eden:S1:S2的比例,所以,我們可以考慮從整體擴大新生代的記憶體空間。假設我們擴大到2G,讓老年代是1G。

9.億級流量電商系統JVM模型引數預估方案

這時會怎麼樣呢?

  • Young區佔2G,Eden區有1.6G, S1、S2各有200M。

這時在分析:

9.億級流量電商系統JVM模型引數預估方案
  • Eden區有1.6G,每秒產生80M的物件放到Eden區,大約1.6G/80=20s放滿。
  • 放滿以後觸發Minor GC, 此時前19s的物件都已經成為垃圾被回收,第20s的物件被轉移到S1區。
  • 此時,S1區有200M,80<S1區空間的一半,所以不會轉移到老年代。這樣第一次GC結束
  • 又過了20s,進行第二次Minor GC,這次Eden區又產生了1.52G的垃圾被回收,之前在S1區的80M物件也已經變成垃圾被回收。新的80M物件被放入到S2區。沒有進入到老年代。
  • 以此類推,第三次,第四次,垃圾物件不會再進入老年代,因此也不會在發生Full GC.

由此分析,大大降低了Full GC發生的頻率。

最終引數設定:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=512M -XX:MaxMetaspaceSize=512M 
  
為了更清晰的看到效果,可以列印GC詳細日誌
-XX:+PrintGCDetails

4. 總結

通過上面的資料分析,我們要養成一個習慣,做任何事情都是要有理有據,不能是拍腦袋就說出來的。一定要能夠經得起驗證的。