此文主要接 storm worker異常重啓原因排查彙總 這篇文章繼續描述。上文中的第三點大概描述了一下造成重啓的原因，這次又有一次詳細的排查過程和思路供參考。
一、背景
今天，另一個同事反應，我們的一個任務在早上4點到10點之間會有嚴重的數據丟失，而這個時間點與一個數據導入任務的時間點是吻合的，經查看此任務的的數據量有將近5億。因此，在這段時間內造成的影響還是挺大的，畢竟都是線上數據。
因此，又重新啓動此任務，可以觀察到，數據丟失率確實增高，因此，就查看各個woker的狀態如何，發現了有一臺機器woker重啓，開始了這個問題的排查過程。
（注：此結果還無法反饋數據丟失的具體原因，僅僅是針對woker重啓的現象排查過程進行記錄）
二、排查過程
1、是否有明顯異常
這個問題的排查請參考storm worker異常重啓原因排查彙總 中的1和2兩點。經查看，可以知道不是這兩種原因導致的。
2、開啓打怪模式
(1) 首先查看supervisor的日誌文件，發現重啓的原因是由於心跳timeout。
但是supervisor檢測worker的心跳，是在本機的一個心跳文件檢測的，不涉及到網絡的問題，因此，就開始懷疑是本物理機有問題。
（2） 查看機器的各個指標
首先查看機器的整體監控，可以看到該機器的CPU整理利用率 80%， 內存整體利用率88%，CPU的負載持續很高，並且不穩定，見下圖：
然後通過top命令，查看各個進程的內存和CPU情況，如下：
（3）根據2中觀察到的結果，具體查看佔用CPU高的線程在做什麼事情，看到是GC線程把CPU打滿了。
注：
1) supervisor檢測worker心跳，是通過檢測本地的心跳文件來完成的，心跳文件的路徑爲：{storm.local.dir}/supervisor/localstate
2) 查看各個線程在做什麼的相關命令爲：
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重啓，基本上是由於機器問題導致的，可以查看機器負載如何。
