Storm 重啟排查（續）

此文主要接 storm worker異常重啟原因排查彙總這篇文章繼續描述。上文中的第三點大概描述了一下造成重啟的原因，這次又有一次詳細的排查過程和思路供參考。

今天，另乙個同事反應，我們的乙個任務在早上4點到10點之間會有嚴重的資料丟失，而這個時間點與乙個資料匯入任務的時間點是吻合的，經檢視此任務的的資料量有將近5億。因此，在這段時間內造成的影響還是挺大的，畢竟都是線上資料。

因此，又重新啟動此任務，可以觀察到，資料丟失率確實增高，因此，就檢視各個woker的狀態如何，發現了有一台機器woker重啟，開始了這個問題的排查過程。

（注：此結果還無法反饋資料丟失的具體原因，僅僅是針對woker重啟的現象排查過程進行記錄）

這個問題的排查請參考storm worker異常重啟原因排查彙總中的1和2兩點。經檢視，可以知道不是這兩種原因導致的。

(1) 首先檢視supervisor的日誌檔案，發現重啟的原因是由於心跳timeout。

但是supervisor檢測worker的心跳，是在本機的乙個心跳檔案檢測的，不涉及到網路的問題，因此，就開始懷疑是本物理機有問題。

（2）檢視機器的各個指標

然後通過top命令，檢視各個程序的記憶體和cpu情況，如下：

（3）根據2中觀察到的結果，具體檢視占用cpu高的執行緒在做什麼事情，看到是gc執行緒把cpu打滿了。

注：1) supervisor檢測worker心跳，是通過檢測本地的心跳檔案來完成的，心跳檔案的路徑為：/supervisor/localstate

jstack ：檢視各個執行緒的堆疊

ps -mp pid -o thread,tid,time ：檢視各執行緒的cpu使用

printf "%x\n" pid :把十進位制執行緒id轉成16進製制，去jstack結果中，檢視執行緒堆疊

剛開始懷疑gc是誘因，但是其實最後判定，gc是結果，因為改機整體利用率太高，導致頻繁的進行gc，最終導致了惡性迴圈。

因此，到這裡基本上可以判定，本機負載太高導致worker無法及時更新心跳檔案，導致supervisor判定其timeout，開始重啟worker。

（4）為什麼此機器負載較高？

經過檢視，因為本機記憶體為128g，storm配置中設定了 supervisor.slots.ports的數量為40個，並且真正的執行的worker也為40個。而且，雖然worker啟動限制最大記憶體為2g，但是實際worker占用記憶體卻很多超過了2g。這是乙個疑點，我還沒有搞清楚。

另外一點，發現有些機器也設定了最大40個worker，但是其實只啟動了20個，因此，這就涉及到了storm分配資源的問題了。對於單個topology來說，storm會盡可能的把其worker分配到單台機器上面，但是並沒有考慮到機器的負載。

總結：對於不容易看出錯誤的worker重啟，基本上是由於機器問題導致的，可以檢視機器負載如何。