阿里程序員不小心把服務器CPU打到100%展示教科書排查過程

你們沒發(fā)現(xiàn)我很近的原創(chuàng)原創(chuàng)少了很多嘛，一是很近花了很多時間做視頻，本來我寫文章就是利用周末的兩天時間，但是現(xiàn)在基本上兩天都要拍攝剪輯了，盡管請了小伙伴做字幕，還是得耗費大量時間在拍攝和剪輯上。

所以我只能利用工作日熬一下才能寫出來了，這周因為要發(fā)布，本來是沒排期寫文章的，你們也看到了我發(fā)了兩個視頻嘛。

但是今天我一發(fā)布就嚇尿了….

事情是這樣的…..

我和小組伙伴很近負責的系統(tǒng)今天上線了，因為涉及到的業(yè)務尤其多所以選擇白天發(fā)布，怕出問題找不到對應的負責人。

看到3點25那個fullgc沒，我發(fā)布上去一分鐘不到就瘋狂GC，我當時就嚇尿了，馬上點了回滾按鈕。

而且我發(fā)現(xiàn)cpu幾乎在我發(fā)布的瞬間，直接打到了峰值。

所幸只發(fā)布了一臺，我緊張的望向了四面，發(fā)現(xiàn)四面的同事沒注重到我，我頓時沒那么緊張了，拿起桌上用剩下的紙巾搽掉了我鬢角馬上留下的汗水。

我其實已經(jīng)知道大概是什么問題了，無非就是死循環(huán)，或者大對象什么的。

但是我還是想找個人承擔這個鍋。

我馬上找到三歪，我問他：你剛才是不是點過我的系統(tǒng)？

他說：對啊，我剛才點了，我本來就經(jīng)常使用你的系統(tǒng)，咋了？（剛好正中下懷嘻嘻）

我說過多少次啊，叫你不要亂點，這已經(jīng)不是第一次了，現(xiàn)在把我的系統(tǒng)點壞了，怎么辦？都怪你。

他：委屈巴巴一副要哭的樣子。

我：誒，算了算了，下次注重哈，我去排查下什么情況，看看你點壞了哪里。

他：丙哥真好，丙哥真棒，丙哥我愛你。

總算是找到背鍋俠了，我就開始排查問題吧。

注：以下代碼都是偽代碼，為了還原排查過程

一般CPU100%瘋狂GC，都是死循環(huán)的鍋，那怎么排查呢？

先進服務器，用top-c命令找出當前進程的運行列表

按一下P可以按照CPU使用率進行排序

顯示Java進程PID為2609的java進程消耗很高

然后我們需要根據(jù)PID查出CPU里面消耗很高的進程

使用命令top-Hp2609找出這個進程下面的線程，繼續(xù)按P排序

可以看到2854CPU消耗很高

image-

2854是十進制的，我們需要轉(zhuǎn)換為十六進制，轉(zhuǎn)換結(jié)果：b26

接下來就需要導出我們的進程快照了，看看這個線程做了啥

再用grep查看一下線程在文件里做了啥

我這里就隨便定位一個，基本上這樣查都可以定位到你死循環(huán)的那個類，那一行，這里你還可以在jstack出來的文件中看到很多熟悉的名詞，至于是啥，你們留言告訴我好了，就當是個課后作業(yè)了。

我寫了個偽代碼，看看當時我為啥會寫出這個死循環(huán)，對了當時我上線的是預發(fā)，也是后臺系統(tǒng)非線上的，雖然都是自己在玩，但是大家還是要引以為戒。

我當時寫了個代碼預備去查出數(shù)據(jù)庫的數(shù)據(jù)，訂正下日期，仔細看沒問題，但是我忘了數(shù)據(jù)庫的偏移值自己去計算了，因為以前都是框架，自己臨時寫的就沒管。

導致每次都能查出10個數(shù)據(jù)，在很后判定的時候就一直true不退出了，其實很后會退出，但是得循環(huán)很多次。

我這里退出的邏輯比較取巧，就是想著很后一次查詢肯定跟我的頁數(shù)不一樣，那就是很后一頁了，那我就處理完退出。

結(jié)果沒想到也是個坑了。

大家寫的時候也要注重很多小坑，這次我就給個demo順便帶大家溫習一下線上故障的排查，下次我可能搞點內(nèi)存泄露，集群宕機什么的故障，這樣就有素材了呀。

假如真出問題，第一時間找個三歪這樣的背鍋俠，排查過程自己去電腦上操作一下，很近有點忙，預備寫個分布式鎖的文章，如何？