架構出錯時如何進行查詢

本篇內容介紹了“架構出錯時如何進行查詢”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. 病號是誰（WHO）？

拿出控制臺診斷儀器，輸入 top 命令一探究竟。我勒個去，不看不知道一看嚇一跳，PID 為 1878 的病號，CPU 占用居然 200% 多。

問題算是定位到了，但是 PID 為 1878 的病號到底是誰，難道真是昨天上線的看門狗 ？

雖然大劉久經職場，但是排查生產問題時，內心還是比較忐忑，畢竟這是生產環境。

說時遲那時快，只見大劉一個命令輸入：

ps -ef | grep 1878

定睛一看，原來是放屁瞅別人，短信服務自己在作祟，和看門狗沒關系，大劉心里一下子平緩了不少。

鍋找到了主兒，其實這個時候大劉完全可以把這個問題甩給短信開發團隊，但是大劉最喜歡做的不是甩鍋，而是打破砂鍋刨到底。

2. 病號哪里出了問題（WHERE）？

為什么 1878 號病人占用 CPU 會這么高呢？

只見黑乎乎的控制臺診斷儀器上，大劉熟練的輸入：

jstack -l 1878 >> 1878號病歷.log

這樣便得到一份 1878 號病人的病歷詳情單，一會兒用得上。

到底 1878 號病人的哪個部位出了問題呢？

話沒說完，只見大劉又在控制臺診斷儀器上，輸入一個：

top -Hp 1878

白板黑字，把 1878 號病人的器官信息全部列了出來。

看到結果，甚是一驚，PID 代號為 8721 的器官占用 CPU 100% 多。

疑惑油然而生，這個 PID 代號 為 8721 的器官是啥，是頭、是眼睛、還是胳膊腿呢？這些器官展示的 PID 列都是昵稱，都這么善于偽裝，如何揭露它的真面目呢？

還好大劉有高招，借助照妖鏡算法，熟練的輸入：

printf "%x\n" 8721

果真使得代號為 8721 的器官，現了真身，真實身份居然是 2211 的呼吸道，怪不得病號一直氣喘吁吁，上氣不接下氣。

到這一步還無法對癥下藥啊，還需要進一步確診 2211 的呼吸道到底出了什么幺蛾子，導致 1878 號病人一直氣喘吁吁，上氣不接下氣？

只見黑乎乎的控制臺診斷儀器上，大劉再次飛一般的在輸入：

grep 2211 -A20 1878號病歷.log

診斷結果隨之顯示在診斷儀器上。

曾經背了很多鍋的大劉，看到診斷結果心里樂了一下，一眼就看出是高并發情況下用了 HashMap 的問題（請大家們自行尋找谷歌、百度，就不在此深入展開啦），終于撥開云霧見青天。

3. 如何對癥下藥（ HOW ）？

在大劉行云流水沒有一絲一毫的拖泥帶水般的神操作下，1878 號病人的診斷也就結束了，這個鍋就徹底被打破了。

術業有專攻，大劉就可以鄭重的告訴短信開發同事具體原因了，捉得病根，開發同事也就可以對癥下藥啦。

大劉這套行走江湖的診斷問題方式你 get 到了沒？大劉自己簡單概括為 2W1H 三板斧：病號是誰、病號哪里出了問題、對癥下藥。

1、病號是誰？（WHO）

• 第一步：采用 top 命令，找出 CPU 占用最高的病號 PID ；

• 第二步：通過 ps -ef | grep PID 查看病號對應的真實身份。

2、病號哪里出了問題？（WHERE）

• 第一步：采用 jstack -l PID >> PID.log 獲取病號的各器官信息的病歷單；

• 第二步：采用 top -Hp PID 拿到占用 CPU 最高的器官昵稱 PID ;

• 第三步：采用 printf "%x\n" PID 根據器官昵稱 PID 的拿到器官真實身份 TID ;

• 第四步：采用 grep TID -A20 pid.log 根據 TID 去病歷單中匹配，確定是哪出了問題。

3、捉得病根、便可拿出醫藥箱，對癥下藥啦。（HOW）

作為程序猿，工作中難免會遇到不少類似這樣的問題。面對問題，你如果像無頭蒼蠅一樣亂撞，撞得頭破血流依然不知道緣由，在背鍋即將成為現實時，那就不妨試試2W1H 三板斧的診斷方式，說不定會幫你快速定位、解決線上問題，畢竟快速的解決生產問題會把損失降到最低。

“架構出錯時如何進行查詢”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！