stormpy内存泄露问题分析


我们的项目中用到了storm,自9月26日起,我们的storm集群频繁出现集群宕掉甚至宕机的问题。

1、现象

storm集群的supervisor机器出现内存泄露,cpu打满,zk集群宕掉,storm nimbus宕掉的情况,严重的甚至出现服务器宕机。我们使用的是storm-0.9.2。

storm-cpu-mem

2、分析过程

2.1、定位出现问题的topology

通过修改python程序名称(我们使用了multilang)的方法,首先定位到出现mem增长的topology是oop,并且是python进程的mem、cpu占用很严重。

2.2、查看日志和增加内存主动回收代码

日志中并没有太多直接能表明mem和cpu增长的异常信息,通过搜索得知有人通过增加主动内存回收代码“解决”了问题,于是我们尝试相同的方法。然而这个方法并没有最终解决问题,反而造成了cpu消耗更多。比较有用的信息是pipe broken这个报错,表明可能是stdin或者stdout的问题。

2.3、转机

9月29日晚,借酒消愁。酒桌上我们再次讨论了这个问题,各自说了直觉中导致问题最可能的原因。我们提到了死循环中某个数据结构不断增长,提到了Java和python通信机制问题。

9月30日storm再次出现内存泄漏的问题,然而此次出现问题的topology是ssn,并且得知运行在线下的pts这个topology也曾出现过这个问题。我们意识到这是一个三个topology共有的问题,它们共有的部分是最可能有问题的——storm multilang python的官方库,storm.py——并且这部分代码中是有死循环的。

在猜想的同时,我们一边重新分析日志,希望能找到可能遗漏的线索,同时进行着另一些“尝试”。

2.4、出现曙光

十一期间storm再次出现问题,我们仍然没有找到问题的原因,之前的所有“尝试”都失败了。我们仍然严重怀疑问题出在storm.py。10月9日上午,我们查看了最新的storm.py代码,并同我们当前使用的storm.py进行diff,最新的代码发现有了不少改动,增加了一些异常处理等代码。我们把新代码上到了线下集群,期望它能有好的表现。下午,新topology抛出了和先前相同的异常,但是这次storm集群mem并没有出现泄漏,到这里我们更相信是storm.py出了问题,只是我们还没分析出内存泄漏点。

10月9日晚上,我们梳理了storm-0.9.3到storm-0.9.5的release log,将其修复的相关bug择了出来,对最有可能的STORM-351做了标记。

2.5、确定问题

10月10日上午,我们首先查看了STORM-351multilang python process fall into endless loop),在这个bug描述的提示下,内存泄漏问题的原因被我们找到了

stormpy

问题出现在readMsg()这个方法。Java进程退出后,python进程依然存在,此时sys.stdin关闭了。readline()返回NULL,line被赋值为空,不满足line == “end”的条件,循环没有退出,msg增加了一个字节”\n”,然后进入了死循环。msg不断增加,导致了内存泄漏。死循环同时导致了cpu被打满。

我们在测试中复现了这个现象。

2.6、其他问题解释

zk集群宕掉是因为zk和storm混布,内存被打满后,zk也挂掉,nimbus挂掉是因为zk挂掉了。

3、解决方案

STORM-351这个bug已经在storm-0.9.3中修复了,使用新的storm.py,并使用storm-0.9.3.jar或更新的jar包编译topology即可。

,

  1. #1 by = =! on 2016 年 01 月 10 日 - 14:58

    今年咋没总结。。

    • #2 by mazhechao on 2016 年 01 月 11 日 - 11:22

      还能没来得及写,真高兴还有人在等看我的总结。

(will not be published)

Are you a human?