文檔屬性
此文檔由東風微鳴編寫。
未經許可，不得向個人或機構傳閱或複製
修改記錄
| 日期 | 作者 | 版本 | 修改記錄 |
|---|---|---|---|
| 2016/5/9 | 東風微鳴 | V1.0 | 創建文檔 |
| 2017/10/30 | 東風微鳴 | V1.1 | 格式調整 |
審閱記錄
| 審閱人 | 職位 |
|---|---|
分發記錄
| 拷貝No. | 姓名 | 單位 |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
參考文件
| 參考文件 |
|---|
概述
某壽險公司的核心繫統是運行在實體機上的，實體機的性能都挺好，但是系統的性能卻不盡如人意。而且之前某壽險公司的核心繫統出過幾次性能上的問題，但是我們總是找不到根本原因。每次都是重啓完了事，也不清楚性能問題究竟對系統造成了什麼樣的影響。
裝上Dynatrace之後，立馬就有關於某壽險公司核心系統的性能告警，告警是關於GC對系統性能造成較大影響(即JVM的GC開銷超過限制)，我們這才知道問題的嚴重性，也知道了從何下手。之後我們定位到導致系統問題的根源，一個是加載的一個用來監控應用各項參數的javamelody的jar包，另一個是因爲system.gc()頻繁地調用fullgc，導致系統“stop the world”時間過長。
分析過程
告警
某壽險公司核心系統安裝上Dynatrace之後，立馬出現如下的告警郵件：
可以清楚的看到，告警郵件上已經明確的寫出了原因，並指出對性能的影響：
原因：進程XXXX_wls_hx_135a@appserver135:0的垃圾回收運行狀況不正常。 由於在垃圾回收過程中花費大量執行時間，因此應用程序進程的顯著掛起時間會持續一段時間。
影響： 過去的 5 分鐘內，該進程用於回收垃圾的時間，總是多於其執行時間 15%。
多於其執行時間 15%！是的，直到看到這個告警，我們才意識到性能問題居然這麼嚴重，GC所花費的時間，在某段時間內已經超過總的執行時間的15%，而且此告警很頻繁。具體如下：
可以從上圖看出，核心系統的大部分機器都出現了性能問題，並且很頻繁，另外有時甚至在長達1、2個小時內，GC時間佔用執行時間超過15%！這是很嚴重的性能問題。而該問題直到我們使用了Dynatrace才首次意識到。
GC問題優化
針對該問題，爲了進一步分析，我們使用了Dynatrace自帶的儀表圖–應用程序進程圖表。具體如下：
從這兒可以看出，告警的時候major gc垃圾收集時間較長，而Dynatrace的major gc就是指會導致“stop the world”的GC。
接下來我們分析了對應的GC日誌，發現日誌中存在大量的system.gc()，並且該每次調用都是執行full gc。關於SystemGC觸發full gc的解釋，我們查到的原因如下：
如果應用使用到NIO框架、DirectByteBuffer或者MappedByteBuffer等功能時，上述情況產生的內存是堆外內存，SystemGC就需要Full GC來回收
之後查看資料，發現一種具體的改進方法，具體如下：
加入參數
-XX:+ExplicitGCInvokesConcurrent，該參數並不會禁用SystemGC，SystemGC還是會被觸發，只是加上該參數後，會使得system gc時執行CMS GC，效率會提高，減少因爲Full GC引起的STW時間。
之後我們在其中一臺上添加了該參數，添加之後與其他沒有添加的做對比，利用dynatrace的自定義儀表板的功能，直接抓取“Suspension Time”(每個時間間隔中GC導致的掛起時間)這一參數做對比畫出曲線圖。發現加了後GC導致的暫停時間大幅下降！由於比較早，該圖找不到了，附上一張使用另一個小工具分析的結論：
可以看到，加了之後GC”stop the world“時間降低了100多秒，full gc次數爲0。
確認加上該參數可以改善gc性能後，我們在覈心的所有jvm裏都添加了改參數。加入後，除了其中一臺機器還會告警，其他機器運行正常。而那臺告警的機器，我們發現還有其他的問題。
javamelody
其中一臺，即使加入了上邊提到的參數，gc的性能還是有問題。具體如下圖：
可以看到，GC暫停時間，其他jvm都是位於10ms左右的數量級，而另一臺則是6000ms左右的數量級！這對應用造成了較大的影響，具體可以通過dynatrace的下圖看出：
直接導致應用，具體到客戶的某一請求，由於gc ”stop the world”導致響應時間大幅增加，原本100多ms就能完成的請求，直接由於gc導致的掛起多花了7000ms！
這次我們使用dynatrace自帶的CPU採樣熱點分析和內存快照分析工具來進行分析。
- 直接通過dynatrace對該臺jvm做heapdump並直接在dynatrace上進行分析，分析結果如下：下圖1-4的實例都是由javamelody這個jar包產生的。
- 通過cpu採樣分析，結果如下：直接看出是javamelody佔用了較多cpu
作爲對比，其他jvm中根本沒有加載javamelody這個包。
而聯繫項目組，得到的答覆是：
javamelody-JVM監控程序。可以用來分析具體的問題點。該jar包會定時（較頻繁）採集應用的相關指定的數據，並且對數據進行打包、壓縮、發送。
而javamelody的這些操作是既消耗CPU又消耗jvm內存資源。對系統的行能造成了較大的影響。而在我們的建議下，項目組拿掉了這個jar包。改用Dynatrace的儀表板和報告.
總結
通過dynatrace，我們發現了核心系統的問題，並快速的分析解決了該問題。解決問題之後，核心系統運行起來平穩而高效。從以前每天都要關注，出了問題抓耳撓腮，變成了今天的風淡雲清。