JVM優化實戰總結
YGC風險和調優：一般的應用服務器的配置是2C4G或4C8G，E區內存分配在1G左右，正常的YGC耗時最多幾十毫秒，然后E區增速不快，YGC頻率不高，用戶使用時是無感知的。
- 風險：
- 機器升級：很多系統在流量大后，低配置機器無法滿足性能要求。會升級到大機器，類似于數據計算的系統對于內存要求高，如32C64G。在這種配置下E區分配內存也會增大，回收這么多對象，YGC的STW時間就會增加，極端情況可能要幾秒鐘回收。并且由于請求量很大，E區的新對象會不斷的產生，造成E區內存增速很快，YGC變得頻繁。就會造成系統頻繁的卡頓，影響用戶使用。
- 分配不合理：在系統上線前，未根據預期并發量、平均每個任務的內存需求大小去評估機器配置、集群規模。未合理的分配好E區的大小，導致E區增速過快，YGC頻繁。
- 優化：可根據預期并發量和任務內存需求大小，評估E區對象增速，合理分配E區大小，保障YGC的耗時和頻率。對于高配機器，可以利用G1回收器去設置預期回收停頓時間，來保證不導致系統卡頓、假死的問題。
FGC風險和表現：
- 風險：FGC非常消耗CPU資源，且FGC的過程會帶來一定STW，系統可能時不時卡死。同時FGC觸發時，如果碰上了程序有問題，有對象長期駐留內存無法回收，就會引發OOM，造成系統崩潰
- 表現：機器CPU負載過高、頻繁FGC報警、系統無法處理請求或者處理過慢
FGC問題的發生情況：
- 系統承載高并發請求，或者處理數據量過大，導致YGC頻繁，而每次YGC后存活對象太多，內存分配不合理，S區過小，導致對象頻繁進入老年代，頻繁觸發FGC；解決：通過jstat分析對應進程的內存和GC情況，看看內存區域分配是否合理
- 系統一次性加載過多數據進內存，搞出來很多大對象，導致頻繁有大對象進入老年代，觸發FGC；系統發生內存泄露，內存里駐留了大量對象塞滿老年代，導致稍微有一些對象進入老年代就引發FGC。解決：通過jstat分析得到可能存在的原因，結合MAT分析內存快照定位。如果jstat分析發現內存使用不多，還頻繁FGC，可能是：永久代里類太多，觸發FGC或誤調用System.gc觸發FGC，該方法執行每次會指揮jvm嘗試執行一次FGC。在jvm參數中加入-XX:DisableExplicitGC：該參數意思是禁止顯示執行GC，不允許代碼來觸發。
JVM性能調優思路：
- 系統開發完后：根據QPS和對象大小計算E區塞滿時間，得到YGC頻率。估算YGC發生后會有多少對象存活，會有多少對象晉升，老年代對象增速、FGC頻率。通過估算后得到一個較為合理的數據，然后分配新老年代空間，E區和S區的比例。原則就是盡可能讓每次YGC后存活的對象遠遠小于S區，避免對象頻繁進入老年代觸發FGC。
- 壓測階段：新系統上線前進行壓測，模擬線上壓力，利用jstat工具觀察JVM運行內存模型：E區對象增速、YGC頻率、YGC耗時、YGC后存活對象大小、老年代增速、FGC頻率、FGC耗時。根據上述指標合理分配內存
- 上線后：上線后需要做線上系統 監控，小公司不上監控軟件就可以運行jstat，然后把監控信息寫入文件，每日定時看看。有能力就上監控平臺，監控機器資源負載情況（CPU、磁盤、內存、網絡）、JVM的GC頻率和內存使用率、系統自身業務指標、系統異常報錯。
- 問題定位：是E區太小YGC太頻繁？S區大小對象晉升老年代過多？大對象晉升閾值設置？動態年齡判斷的閾值？針對上述數據進行問題定位后，采取對應優化措施。
- 內存評估：根據每次YGC的存活，評估S區大小設置是否合理、評估多久進行一次FGC，產生的STW是否可以接受
- 如果負載增加10倍，100倍：增加服務器數量，根據負載的增比。同比增加機器數量，機器配置、使用更高配置機器、意味著更快速的處理速度和更大內存。響應時間敏感且內存大的，建議采用G1
- 優化原則：盡量讓每次YGC后的存活對象小于S區的50%，都留存在年輕代，盡量不讓對象進入老年代，減少FGC頻率，避免頻繁FGC對JVM性能影響
如何根據線上監控來排查問題：
- 首先看下機器資源負載情況，比如看下CPU使用率，如果過高就檢查下為何CPU那么高
- 看下磁盤IO負載、看下磁盤發生了多少數據量IO，一些IO的耗時。關注一下本地磁盤的使用量和剩余空間，有時候一些系統bug會一直往本地磁盤寫東西。
- 然后就是機器內存使用量，看下JVM監控，了解各個內存區域使用量變化，FGC頻率
- 最后就是機器上的網絡負載，看看通過網絡IO讀寫了多少數據，一些耗時。
- 一般情況就是CPU、內存、FGC。還有一些業務報警，比如一些限流，惡意請求，代碼異常捕獲也要接入警報，有問題上報到監控平臺。
服務假死排查：接口無法調用，并不是直接拋出了OOM異常，因此很難去直接看線上日志，針對服務假死可以先通過命令去檢查資源使用量
- 服務假死的兩種可能性：
- 服務可能使用大量內存，內存始終無法釋放，因此導致了頻繁GC
- 機器CPU負載太高，也許是某個進程耗盡了CPU資源，導致服務的線程始終無法得到CPU資源去執行，也就無法響應接口調用請求。
- 排查：
- cpu占比高：
- 通過top命令檢查進程消耗資源情況，如果CPU消耗很高，執行top -c顯示進程列表，輸入P，按照CPU使用率排序。
- 定位耗費CPU的進程、然后執行top -Hp 進程id，輸入P，按CPU使用率排序，定位進程中耗費CPU的線程。
- 使用printf %x\n命令把線程pid轉成16進制，然后通過jstack 進程id|grep 16進制編碼打印出堆棧信息，通過堆棧信息確認有問題的代碼。
- CPU占比低但內存使用率高：
- CPU消耗低但是內存消耗高，代表服務進程幾乎快把分配給它的內存消耗完了，如果長期保持這個消耗量，說明GC時候內存并沒有被回收
- 內存使用率高了會引發：頻繁的FGC，GC帶來STW影響服務、內存使用率過多，JVM發生OOM、內存使用率過高，可能導致這個進程因為申請內存不足，直接被操作系統把這個進程殺掉
- 使用jstat分析jvm運行情況，內存使用率很高，頻繁gc，但是GC耗時很短，說明這個情況正常。并且頻繁GC的時候，服務也沒有反饋假死，可以排除是FGC帶來的問題
- 如果JVM發生OOM掛了，掛掉的時候服務就無法訪問了，但是反饋的是假死，而不是服務不可用。并且日志里未看到OOM異常，就可以排除不是發生了OOM
- 剩下的可能就是進程申請內存過多，導致內存不足，os可能殺死這個進程。導致服務無法訪問，但是進程監控有腳本，進程被殺掉了，會有腳本自動把進程重啟，所以過一會兒可能其他服務訪問又可以。造成假死。在線上系統運行一段時間后，同top命令和jstat命令觀察一段時間，發現jvm耗費超過50%內存時，迅速導出內存快照，用MAT分析。定位到大對象的產生原因。
內存泄露處理：
- 通過jstat去定位是否是內存分配不合理，或者去看下是否永久代的類過多
- 如果不是，則通過jmap導出內存快照，利用jhat、MAT工具來分析內存
- MAT分析：點擊Leak Suspects進行內存泄露分析，會顯示一個餅圖，提示哪些對象占用內存過大
- 然后針對大對象實例，找開發去排查系統的代碼問題，為何會創建大量對象，而且始終回收不掉
MAT分析內存快照：
- 點擊或有提示Leak Suspect Repost，進行內存泄露的分析
- 餅圖會展示大對象內存占用情況，可能存在內存泄露。并會有詳細的問題告訴你什么結構占據了大量內存
- 通過Details查看詳細說明，查看到底是什么對象在內存里占據了過大的內存
- 果發現了某個線程在執行過程中創建了大量對象，就可以點擊See stacktrace，看到線程執行代碼堆棧的調用鏈。找到是哪個方法造成了大量對象
本文來自博客園，作者：難得，轉載請注明原文鏈接：http://www.rzrgm.cn/zhangbLearn/p/18829139
浙公網安備 33010602011771號