億級流量電商系統JVM模型引數二次優化
尊重原創版權: https://www.gewuweb.com/hot/10913.html
億級流量電商系統JVM模型引數二次優化
億級流量電商系統JVM模型引數預估方案，在原來的基礎上採用ParNew+CMS垃圾收集器
一、億級流量分析及jvm引數設定
1. 需求分析
大促在即，擁有億級流量的電商平臺開發了一個訂單系統，我們應該如何來預估其併發量？如何根據併發量來合理配置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但會產生多大的物件呢？
我們假設訂單物件的大小是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
這樣設定到底行不行呢？有沒有問題呢？我們來看看執行時資料區：
根據計算
- 整個堆空間3G
- Eden區800M
- s1/s2各100M
- 方法區512M
- 一個執行緒1M
按照這個模型來分析，得到如下結果：
- 大促期間1s產生80M的物件資料。我們知道物件資料都是放在Eden園區，Eden園區一共800M，那麼大約10s就放滿了，放滿了就會觸發Minor GC
- 觸發Minor GC的期間，會Stop The World暫停業務執行緒。在第10s觸發MinorGC的時候，前9s的720M資料都已經變成垃圾了，會被回收掉，最後1s的80M資料由於還有物件引用，只是暫停了業務執行緒，因此不是垃圾，不能被回收。會被放入S1區。
- 在Survivor區有一個物件動態年齡判斷機制。什麼是物件動態年齡判斷機制呢？
當前放物件的Survivor區域裡(其中一塊區域，放物件的那塊s區)，一批物件的總大小大於這塊Survivor區域記憶體大小的50%(-XX:TargetSurvivorRatio可以指定)，那麼此時
** 大於等於 ** 這批物件年齡最大值的物件，就可以直接進入老年代了，例如：Survivor區域裡現在有一批物件，年齡1+年齡2+年齡n的多個年齡物件總和超過了Survivor區域的50%，此時就會把年齡n(含)以上的物件都放入老年代。這個規則其實是希望那些可能是長期存活的物件，儘早進入老年代。
** 物件動態年齡判斷機制一般是在minor gc之後觸發的。 **
也就是說當在Survivor區經過幾代的回收以後，如果物件總和大於Survivor區域的一半，則會直接放入到老年代。Survivor是100M，第10s的物件是80M，大於100M，會直接將這個物件放入到老年代。
- 老年代一共有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。
這時會怎麼樣呢？
- Young區佔2G，Eden區有1.6G， S1、S2各有200M。
這時在分析：
- 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. 總結
通過上面的資料分析，我們要養成一個習慣，做任何事情都是要有理有據，不能是拍腦袋就說出來的。一定要能夠經得起驗證的。
二、億級流量jvm引數優化--使用parNew和CMS垃圾收集器
1. 需求分析
上面的引數設定，幫我們解決了多次觸發Full GC的問題，通過調整引數以後，我們看出在預期正常情況下，基本不會觸發Full
GC。但如果有意外情況呢？比如，我們的一臺伺服器能夠承受的最大併發量是400/s，但如果在秒殺的時候，併發量超過了這種情況是在不發生意外的情況下。假如併發流量達到1000，記憶體模型是怎麼樣的呢？
根據這個估算模型，正常情況下訂單系統可以承接的訂單併發量是400單/s，但遇到某一個大促活動，很可能併發量衝到700單/s,
1000單/s，這是一秒產生的垃圾就不是60M了，可能是120M，甚至更多。根據之前的分析，這時又會頻繁的觸發Full
GC了。當然了，我們有很多辦法來控制併發量，比如限流、擴容。但這裡我們從JVM的角度來分析，如何處理這個問題。
正常情況我們的jvm引數是如下設定：
‐Xms3072M ‐Xmx3072M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
經過上面的分析，這樣設定可能會由於 ** 動態物件年齡判斷原則 ** 導致頻繁full gc。於是我們設定如下JVM引數，儘量避免觸發full GC
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
2. JVM優化
這個原理在上面已經說過了，但是如果併發量從峰值400單/s，一下衝到700~1000單/s。這時候，很顯然，又會觸發Full
GC了，因為記憶體物件從原來的80M,變成了160M甚至更多，Survior區200M空間，他的一半小於160M,
所以會直接放入到老年代。針對這個問題，我們來做引數優化。
優化一：分代年齡從15變成5
系統預設的分代年齡是15，也就是一個物件在Survivor兩個區輪迴15次才會進入到老年代。15次大概是多長時間呢？我們來計算一下，按照引數來分析一下記憶體模型，如下圖：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
每秒鐘產生80M垃圾，放入到Eden區，Eden區一共1.6G，預計20s放滿，觸發Minor GC,
然後大部分物件被回收，只有一小部分物件進入到Survivor區。第二次回收的時候，上次進入Survivor區的大部分物件被垃圾回收，另一部分進入到另一個Survivor區。這些進入到另一個Survivor的物件要經歷15次Minor
GC，也就是年齡是15的時候，被轉移到老年代，花費大約20s*15約5分鐘的時間才能進入到老年代。其實這些長期存活的物件都是java執行或者spring執行是的一些java.lang.String,
java.util.Math, 和一些bean物件。既然這些物件本身是長期存活的，那麼我們就沒必要讓他經歷那麼多代才進入到老年代。
我們完全可以將預設的15歲改小一點，比如改為5，那麼意味著物件要經過5次minor gc才會進入老年代，如果經歷5次Minor
GC還沒有被回收，我們完全可以認為她就是要長期存活的物件了，將其移動到老年代，而不是繼續一直佔用survivor區空間。整個過程時間不到兩分鐘。
設定引數如下：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5
優化二：大物件直接進入老年代
對於多大的物件直接進入老年代合適呢？這個一般可以結合你自己系統看下有沒有什麼大物件生成，預估下大物件的大小，一般來說設定為1M就差不多了，很少有超過1M的大物件，這些物件一般就是你係統初始化分配的快取物件，比如大的快取List，Map之類的物件。
設定大物件直接進入老年代使用的引數：-XX:PretenureSizeThreshold
引數設定如下：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M
優化三：替換垃圾收集器為ParNew + CMS
JDK8預設使用的垃圾回收器是-
XX:+UseParallelGC(年輕代)和-XX:+UseParallelOldGC(老年代)，通常使用Parallel會有什麼問題呢？經驗告訴我們，當系統記憶體較大的時候（超過4G，經驗值），系統對停頓時間是比較敏感的。
通常大於4G記憶體，我們可以採用ParNew + CMS垃圾收集器。可不可以使用G1收集器呢？G1收集器通常是記憶體大於8G時使用的。
記憶體小於8G時，在jdk8中G1收集器的演算法耗費的記憶體要比CMS多。所以這裡我們替換垃圾收集器為ParNew + CMS。設定使用ParNew +
CMS的引數是： ** -XX:+UseParNewGC -XX:+UseConcMarkSweepGC **
經驗： 很多使用jdk8的公司都是用時ParNew + CMS垃圾回收
引數設定如下：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
替換成ParNew + CMS垃圾收集器能解決上面併發流量達到700~1000單/s的問題麼？我們來分析一下：
1） 當併發流量導到700單/s的時候， 原來每秒產生80M垃圾，現在可能達到160M，那麼年輕代Survivor放不下，會直接放入到老年代。
2）當兵發流量大了的時候，本來系統能承受的是400單/s,
但是突增到500單/s的時候，原來每秒可以處理一個訂單，現在可能1秒處理不完了，要2秒甚至更多。那麼就有可能在垃圾回收的時候，2s內的物件的引用關係都還在，不能被回收，剛好又大於新生代一半的空間，也會被直接放入老年代。
3）經過上面的優化，發生一次Minor GC，大約要20s,
老年代有1G空間，1G/160M*20/60=2分鐘。2分鐘觸發一次GC，通常高峰流量也就半個小時左右。2分鐘觸發一次GC，這也不太合適。
優化四：設定CMS收集器的引數
1） 避免併發失敗引數設定
在CMS收集器那塊我們說過，CMS正在收集垃圾但還沒有完成的時候，又產生了新的垃圾，導致再次觸發垃圾回收，這就發生死迴圈了，這就是concurrentmode
failure併發失敗。為了避免併發失敗，這時會停止CMS垃圾回收的全部執行緒，進入到Serial
Old序列垃圾收集。序列速度是很慢的，嚴重影響使用者體驗。我們儘量不要讓這種情況發生。因此，我們設定垃圾回收引數：‐XX:CMSInitiatingOccupancyFraction，我們設定老年代達到一定比例比如80%就出發Full
GC，留出足夠大的空間給大物件，這樣就不會觸發Serial Old了。
這個值預設是92，也可以設定成80，但設定成80就表示，剩下20%的記憶體空間正常情況下處於閒置了。
引數設定如下：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
‐XX:CMSInitiatingOccupancyFraction=92
2）壓縮整理引數設定
我們可以設定在發生Full GC之後進行記憶體空間的壓縮整理。這裡涉及到兩個引數，一個是開啟壓縮整理，另一個是觸發幾次Full GC整理一次記憶體空間。
-XX:+UseCMSCompactAtFullCollection：FullGC之後做壓縮整理（減少碎片）
-XX:CMSFullGCsBeforeCompaction：多少次FullGC之後壓縮一次，預設是0，代表每次FullGC後都會壓縮一次
這個引數是說執行多少次Full GC以後進行一次壓縮。如果其值是3，則表示執行3次Full GC，進行一次壓縮整理。
在觸發了CMS垃圾回收之後，進行記憶體整理，也會對效能有一定的影響的。
因為他也會STW。這個過程不會特別慢，這和剩餘的物件有關，剩餘的物件少，效率就高。剩餘的物件多，效率就低。因為在整理的過程中，物件的地址會發生變化。
對於我們上面的案例，我們可以設定每次垃圾回收後都進行整理，為什麼可以這麼設定呢？因為我們full
GC發生的頻率很低。偶爾搞一次大促呢？也沒關係，大促的前面二三十分鐘流量最高，二三十分鐘觸發一次Full GC沒關係的，因為大促基本結束了。
如果系統壓力比較大，觸發Full GC很頻繁，這個引數就不要這麼設定了。可以設定-XX:CMSFullGCsBeforeCompaction為3次，5次。
不做碎片整理可不可以呢？
最好不要，因為如果不做碎片整理，老年代的碎片就會越來越多，正常的大物件都放不下了。
引數設定如下：
‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐XX:SurvivorRatio=8
‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
‐XX:CMSInitiatingOccupancyFraction=92 ‐XX:+UseCMSCompactAtFullCollection ‐XX:CMSFullGCsBeforeCompaction=0
reCompaction=0