此文主要接 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重启，基本上是由于机器问题导致的，可以查看机器负载如何。