一、問題發現
Prometheus報警某服務的一個節點 Old GC過多,須要排查。html
二、查看GC日誌
使用tail -f gc.log
命令查看異常節點的GC日誌,從日誌能夠看出Young GC過於頻繁,居然在1s內有9次Young GC: 使用
tail -f gc.log
命令查看正常節點的GC日誌,從日誌能夠看出,正常節點,好久才進行一次Young GC: 兩個節點的JVM參數配置是徹底同樣的,而且負載均衡策略使用的是Ribbon默認的輪詢策略,也就是說,兩個節點可以接受到的請求是均衡的,不存在一個節點比另外一個階段負載大的狀況。 使用
jstat
命令查看異常節點的Young GC頻率,發現確實存在異常: java
三、使用jps
命令找出該應用進程的pid,再使用top -Hp pid
命令查看該進程下佔用CPU最多的線程id:
四、將查到的線程id 9182,使用printf "%x\n" 9182
命令,轉換爲16進制:
五、使用jstack 9088 | grep 23de -A 30
命令查看堆棧信息(屢次查看):
第一次: 第二次:
該線程一直處於Running狀態,而且兩次查看中發現,堆棧中有共同的方法調用,懷疑問題可能發生在
RedPackUtilV3.java:169
處,須要查看業務同窗代碼。負載均衡
六、查看業務同窗代碼
發現極有多是while循環中break條件一直沒成立,致使了死循環,最後就請業務同窗本身檢查代碼邏輯了。ui
原文出處:https://www.cnblogs.com/cuizhiquan/p/11123559.htmlspa