storm 拓扑worker time-out重启问题排查

storm版本：0.9.0.1
异常描述：拓扑运行一段时间后、个别机器的worker进程会出现time-out重启的情况，而该worker进程重启后，并不能正常工作、在spout不断出现fail、原因不明。将拓扑kill掉、重启该拓扑，则可以正常运转。

观察到出现worker time-out重启的情况，通常都出现在cpu load出现一个小峰值的时间点、如下图所示。

且worker重启，90%的情况都是出现在同一台机器上，因此错以为是该机器cpu负载相对较高，导致的worker无法正常更新心跳包导致的进程重启。

因此想通过延迟supervisor.worker.timeout.secs的超时时间，用以解决问题。例如设置为600s（默认30s）。
在topology中增加了一下配置，

 config.put("supervisor.worker.timeout.secs", 600);
 StormSubmitter.submitTopology(topoName, config, builder.createTopology());

设置了以上参数后、可以在该topology对应的storm ui看到该参数已经配置了，如下图所示：

到这里，笔者以为配置已经生效，其实不然，后面又出现了worker重启、查看日志发现，仍然是超过30s之后未更新心跳包就被kill掉了。说明配置未生效。

排查storm目录底下的worker日志，发现supervisor.worker.timeout.secs的配置仍为30，与程序日志的600s的配置不符合。

于是修改storm.yaml配置，增加以下配置（未重启storm的supervisor）：

supervisor.worker.timeout.secs：600

查看storm目录下的worker日志，发现获取到的supervisor.worker.timeout.secs配置是600s。笔者又以为生效了，但是后有出现worker time-out的情况，还是30超时就会被kill掉。

于是意识到，必须要重启supervisor，配置才会生效。重启后，配置果然生效了，延迟了超时时间、后面基本没有出现worker time-out重启的情况。（笔者根据业务情况、将supervisor.worker.timeout.secs设置为300s，由于五分钟的延迟，对于业务没有太大影响，因此就如此简单粗暴地处理了）。

后面相对空闲时，又对该问题进行排查。发现不断出现的worker time-out情况的机器、该机器的gc情况比较异常，异常情况如下：

• .异常机器的gc次数比正常机器少一半。
• .异常机器的gc时间比正常机器多一倍。

由上述的异常情况、笔者认为是该worker的gc的时间过长、才导致worker time-out超时。
通过java dump将java堆栈信息打印出来分析、发现该机器是由于bolt处理太慢、才出现的频繁full gc，才导致上述情况发生，于是可以对症下药，进行优化啦~