今天斷斷續續的收到管理平臺的異常報警,cpu佔用太高和jvm old佔用太高,這個時候趕忙去排查緣由,下面記錄了個人排查過程,可能裏面還有不正確的地方,歡迎各位大佬指正,也歡迎你們關於相似的案例一塊兒交流,下面就看我關於此次排查的過程把服務器
①經過 top 命令找到佔用cpu最高的 pid[進程id]
jvm
定位到pid是 1469線程
②經過 top -Hp pid 查看進程中佔用cpu太高的 tid[線程id]debug
③經過 printf pid |grep tid 把線程id轉化爲十六進制3d
④經過 jstack pid | grep tid -A 30 定位線程堆棧信息日誌
佔用cpu太高的線程有兩個,其中一個是打印異常日誌的(會new 對象),還有gc線程orm
打印異常堆棧cdn
這個佔用cpu根據堆棧信息就能夠定位,看下代碼,能夠發現new 對象,且打印全棧信息對象
其中ExceptionUtils.getFullStackTrace(e) 屬於commons.lang包blog
能夠發現上面兩個方法會建立不少對象且打印堆棧信息佔用內存
gc線程
能夠發現佔用cpu太高的線程進行大量的gc
能夠發現伊甸園區和老年代都已經滿了,且進行了大量的FGC
指標介紹
S0:年輕代第一個倖存區(survivor)使用容量佔用百分比
S1:年輕代第二個倖存區(survivor)使用容量佔用百分比
E:年輕代伊甸園區(eden)使用容量佔用百分比
O:老年代使用容量佔用百分比
P:perm代使用容量佔用百分比
YGC:從應用程序啓動到當前採樣時年輕代gc的次數
YGCT:從應用程序啓動到當前採樣時年輕代gc的時間
FGC:從應用程序啓動到當前採樣時老年代gc的次數
FGCT:從應用程序啓動到當前採樣時老年代gc的時間
GCT:從應用程序啓動到當前採樣時gc總耗時
使用 jmap -dump:live,format=b,file=name.dump pid 導出dump文件,通常dump文件會比較大【個人這個2.94G】,而後下載【能夠用 sz name.dump】到本地用jvisualvm【jdk自帶的,在bin目錄下】分析
首先看下dump文件的概要
看看這些大對象都是什麼
發現前面幾個大對象都和 ElastaicSearchStatusException對象有關,而後這個管理平臺用到es的地方只有一處,就是作數據漏斗,記錄廣告檢索在哪些步驟過濾掉,方便產品和運營查看廣告被過濾的緣由,而後翻開代碼
其中 RestClientFactory.getRestClient().search(searchRequest)的 search方法一步一步跟進,發現拋ElasticSearchStatusException的地方
其中parseResponseException方法會拋出ElasticSearchStatusException異常,至於這兩個地方具體是哪一個步驟拋的,能夠繼續研究es代碼判斷或者 遠程debug斷定,我這裏先無論了,反正咱們能知道es出問題了
其實正是由於這裏拋異常纔會致使建立大量對象,由於異常在上面提到的打印異常日誌的地方也會建立對象,老年代佔用太高,致使大量fgc
但es這裏爲什麼會有異常?
我登陸到es的管理平臺查看es的索引,發現有的索引沒有建立,索引的建立是有任務去建立並實時寫入數據的,發現那個任務已經停了。
歡迎關注公衆號 【天天曬白牙】,獲取最新文章,咱們一塊兒交流,共同進步!