linux服務器cup100%問題排查

一、出現問題
在發現公司門禁服務無法開門的第一時間,去線上服務器上查看了一下進程的運行情況,具體運行如下:

 

 

 

第一次在查看的時候發現並沒有我需要的服務entranceguard進程(圖片是後續截圖的)

二、第一時間啓動服務
在察覺到服務掛了之後,第一時間就是讓服務重新啓動,所以運行了項目下的python腳本,具體運行如下:

 

 

此時再次使用ps -ef | grep java 命令時發現服務已經正常運行了,解決了第一緊急事情,然後接下來是對這次事件進行排查:

三、排查問題:
在排查問題的第一時間,通過top命令查看了當時的服務器的cpu與及內存及負載均衡的相關情況,發現我的進程佔用cpu 100%而且整個負載超過1.0,所以此時發現運行有問題;

 

 

此處找出佔用cpu過高的java進程id:761,然後對該進程的每個線程的運行情況;

四、查看佔用cpu過高的進程中所有線程的運行情況:
使用ps -mp pid -o THREAD,tid,time命令查看該進程的線程情況,發現該進程有一個線程佔用率很高,具體如下:

 

 


此處發現線程pid:795 佔用cpu99.7%,基本問題線程已確定,然後定位線程的具體問題:

五:定位線程具體問題:
查看該線程的堆棧情況,先將線程id轉爲16進制,使用printf “%x\n” tid命令進行轉換,因爲線程堆棧情況記錄的是線程的16進制id:

 

 


然後根據該id通過命令 jstack pid |grep tid -A 30(pid:進程id,tid:線程id) 查出具體問題如下:

 

 


此時發現log4j打印dubbo日誌的線程已阻塞,發現是線程無法寫入,基本定位問題可能是磁盤空間的問題;

六、查看磁盤空間大小:
通過命令 df -h查詢發現/dev/vda1該文件夾使用率100%,磁盤空間爆滿

 

 


接下來通過命令du -sh *查看具體文件夾佔用內存情況發現我的項目tomcat佔用了90多G,

 

 

 


最後定位問題是在tomcat中的catalina.out控制檯日誌輸出過大,造成磁盤空間佔滿,然後系統無法繼續寫日誌,從而導致剛好dubbo服務打印的日誌一直處於死鎖狀態,該線程陷入死循環,大量消耗cpu,最終的結果是內存溢出,殺死進程了;

七、解決問題:
一、刪除掉了catalina.out文件,top指數直接下降:

 

 

整個服務運行正常;
二、修改代碼:
將控制檯打印的日誌給禁用掉,並限制打印日誌的大小,因爲我的日誌裏面有打印base64位的圖片日誌,該日誌所需空間太大,所以對日誌禁用及限制;

八、本次感悟:
1、打印日誌的時候不要過多,但是要清晰,就是核心問題體現出來;
2、控制檯的日誌可以不用打印,因爲配置了指定的日誌輸出文件,而且控制檯的日誌有許多的冗餘信息;
————————————————
版權聲明:本文爲CSDN博主「遊蕩程序洋」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/lonyness/article/details/82628988

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章