Storm 1.2.2与Kafka 1.1.0：Supervisor反复启停Worker进程问题咨询

退出码137其实是128 + 9的组合——128是进程被信号终止的基础码，9对应的是Linux系统的SIGKILL信号。这意味着你的Worker进程不是正常退出，而是被操作系统强制杀死了，最常见的原因就是内存不足（OOM，Out Of Memory）：当Worker进程占用的内存超过了系统允许的阈值，系统的OOM Killer机制会直接干掉这个进程来释放内存，避免整个机器崩溃。

咱们一个一个拆解这两个参数：

• supervisor.worker.shutdown.sleep.secs：这个参数是用来控制Supervisor在发送停止指令后，等待Worker自行优雅关闭的时长，如果超时没关闭才会强制杀进程。但你的问题是Worker在加载Executor的过程中就被干掉，完全和“优雅关闭”的流程不沾边，所以调整这个参数根本解决不了你的问题，别在这浪费时间啦。

• worker.childopts增加JVM内存：这个是大概率能解决问题的方向，但得注意正确配置。
  因为137的核心原因是JVM内存不够用导致OOM，所以你需要通过worker.childopts给Worker的JVM分配更大的堆内存，比如把原来的-Xmx512m改成-Xmx1024m（具体数值要根据你的机器可用内存来定，别贪多导致机器整体内存不足）。另外还要注意Storm的worker.heap.memory.mb参数，这个是Supervisor给每个Worker进程预留的内存上限，JVM的-Xmx设置不能超过这个值，不然还是可能触发系统的内存限制。

除了调内存，你还可以做这几件事确认问题：

• 查看机器的dmesg日志，里面会明确记录是不是OOM Killer杀了你的Worker进程，能看到类似Out of memory: Kill process ... (java) score ...的日志。
• 检查拓扑的并行度配置，如果给每个Worker分配的Executor数量太多，也会导致内存暴涨，适当减少并行度或者增加Worker数量分散压力。
• 排查你的Spout/Bolt代码，有没有内存泄漏的情况，比如大量缓存没清理、对象重复创建没释放，这些也会慢慢把内存撑爆。

内容的提问来源于stack exchange，提问作者DP63