記錄線上RT規律性增加問題排查

背景

營銷中心一個新工程上線，工程上線後，監控平臺顯示RT水位呈規律性上漲降低

初次排查

初次看監控圖，認爲是redis key批量同時失效致使的，由於波峯的相隔時間正好是15分鐘，redis的key失效時間也正好設置了這個時間。同時，當時公司運維反饋給個人，該表的sql請求量較大，15分鐘調用了 36530次，佔了該庫性能的80%.

從鏈路監控中發現部分mysql的RT很高。

初次問題定位

結合db響應時間，初步定位問題爲：緩存穿透後，大量的sql請求量致使RT上升。

可是其實沒法解釋規律性上漲問題。

因而乎，增長緩存擊穿保護，發佈上線，發現RT居然下來了！認爲問題已經解決。

問題再次出現

過了個端午，今天再看RT狀況，又恢復第一張圖的狀況

問題排查

感受問題並不是當初想象的那樣。因而檢查服務器狀況，發現服務器CPU使用也很是奇葩。

因而使用jstack 排查工程中多線程使用狀況，發現無異常。

使用 top -Hp pid 查看CPU使用最頻繁的線程

printf "%x\n" 19838 獲取到十六進制值 4d7e

jstack 19832 | grep "4d7e" 查看線程狀況

發現消耗CPU最多的居然是gc線程

jstat -gc 19832 1000 查看GC狀況

發現大bug了。老年代只配置了64M，線上一直在fullgc，端午三天已經fullgc了19萬次多了。。好了，能夠找運維小哥哥喝茶去了

結論

線上老年代配置的過小，致使系統一直在fullgc，fullgc的時候STW，阻塞用戶線程，通常阻塞時間在100ms左右，致使RT飆升。fullgc後恢復正常，rt恢復，而後再次繼續fullgc。

思考

1. 監控平臺缺乏對jvm監控

2. 對於請求量大的接口，評估緩存擊穿風險

3. 問題排查要結合CPU，內存，IO，JVM多方面同時考慮