服務器CPU負載太高問題查詢記錄

這是一個未解的疑問

---

週四晚上，有一臺服務器遇到一個很怪異的現象：有流量訪問時，CPU負載升到100%，可是內存使用量不大，經過NGINX切流，不接受HTTP請求，服務器又自動恢復了，本來打算準時游泳的腳步，就被問題纏住了=-=

因而咱們就開始登錄有問題的服務器，經過日誌和監控查看具體問題。在這切流先後，ActiveMQ消息服務和DUBBO的RPC調用，都是處於運行中的，區別在於，切流前的CPU負載忽然升高到100%，可是內存使用量只是升高，沒到OOM的地步（因此沒有dump文件）。

開始查看服務器：

1：經過top服務器，定位到PID爲30284的jvm進程佔用CPU到達100%

2：顯示線程列表，按照CPU佔用高的線程排序

[admin@xxxxx]# top -Hp 30284

3：找到最耗時線程的PID，而後將它轉成16進制的格式

[admin@xxxxx]# printf "%x\n" 31448 77e0

4：經過jstack命令查看jvm，grep耗時線程的詳細堆棧信息

[admin@xxxx] # jstack 30284 | grep 77e0 -A 60

---

進一步分析

堆棧信息比較多的是MQ線程處於TIME_WAIT狀態，等待消息出隊，經過觀察源碼，發現這裏一直在計算，不過MQClient一直在要等待消息處理，因此這個狀態好像也沒啥問題=-=

經過查看業務日誌，發現消息消費onMessage特別耗時

有些消息處理已經超過100000ms，根本算不上正常(ಥ_ಥ)，對比與其它幾臺服務器，一樣的應用，但消息處理速度很正常，其它各項指標也是正常，只能先將這臺服務器切流，初步懷疑這臺服務器的MQ消費有特殊的問題 。

另外跟蹤幾個消費的消息，發現有個數據庫查詢方法特別耗時，致使整個消息處理變慢

查看其它服務器的消息處理狀況，這個查詢方法速度雖然也要一到兩秒，但也算是正常。但這臺機器查詢速度慢應該是受到服務器CPU高負載的影響，畢竟redis和JDBC鏈接也會受到影響。

將這臺服務器暫時切下，等待消息處理結束，服務器就自動恢復了，可是是什麼引發服務器的CPU負載升高的「元兇」還沒找到，怎麼也解釋不通，還須要繼續觀察。

---

小結：

一、學習到簡單定位佔用CPU高的線程在作什麼操做的服務器命令 二、ActiveMQ這個消息中間件仍是不熟悉，須要去了解一下 三、dao層查詢慢，業務上須要進行優化這個場景 四、要去了解服務器各類狀態的影響

---

參考資料：

一、服務器TIME_WAIT和CLOSE_WAIT詳解和解決方法

二、ActiveMQ源碼解析（二）會話是什麼