一个oom（out of memory）问题的定位和“”解决“”

         先说下背景：

         主调模块有n台机器， 被调模块有6台机器（均衡地提供服务）， 他们之间是网络调用。 而且， 被调模块在收到主调模块的网络包后， 先立即回一个响应给主调模块， 然后做自己的事情。

         从去年到今年， 一直有个告警， 差不多每两个星期会遇到一次，  主调的log显示， 调用被调机器时超时， 而且每次根据log分析， 都是集中在某一台被调机器上。 于是， 每次都以为是机器本身的原因， 于是找运维同学， 替换掉被调机器， 问题得到暂时解决。 后来发现， 即使不处理， 这个问题也会自己解决（实际是oom导致进程重启所致， 后续再表）

         后来， 操作系统组的同学和运维同学怀疑是内核泄露(他们说不是业务代码的内存泄露)导致oom， 最后也没有确定的结论。

         后来呢？ 被调模块的6台机器要缩容， 原来的问题就加剧了， 并且频繁发生。

         最开始以为是主调的time wait太多（大约10000个）， 全方位降time wait, 但问题得不到解决。而且被调是直接立即回包的， 按道理说， 不应该存在慢的情况， 几乎就确定是主调的问题了。 

         后来摸索了很久， 去看被调模块， 发现内存异常。 某哥怀疑内存泄露， 并且内存泄露能解释遇到的所有现象， 而且信息显示确实oom了。 原来， 在内存吃紧的情况下， 即使是立即回包， 也可能很慢很慢。

         我部署valgrind并用valgrind分析， 没有检测出definite的内存泄露， review代码， 也没有发现可疑的地方。 于是我又怀疑， 是不是被调机器上别的程序有内存泄露， 导致当前业务进程被oom kill,  但是， 并没有什么证据。

        目前唯一可以确定的是， 是oom导致了被调的某台机器在某个时间内很慢，  导致主调在设定时间内没有收到回包， 于是产生了告警。 确实找不出来原因， 但问题还是存在，要解决啊。 

        没辙了？非也！ 在公司，  解决问题才是首要目的， 我在crontab中加了个定时重启的服务， 问题得到解决。 虽然会较小地影响服务， 但其实可以忽略。

        后来持续观察， 服务一直运行得好好的。