博客讲述了在主调模块与被调模块间网络调用过程中出现的OOM问题，表现为周期性超时，集中在某被调机器。起初怀疑是机器、内核泄露或主调模块的TIME_WAIT过多，但排查未果。最终发现被调模块内存异常，可能存在内存泄露，通过valgrind分析未找到确切原因。为了解决问题，采取了定时重启服务的临时措施，虽然有轻微影响，但保持了服务稳定。后续从操作系统层面找到根本原因并解决。
先说下背景：
主调模块有n台机器， 被调模块有6台机器（均衡地提供服务）， 他们之间是网络调用。 而且， 被调模块在收到主调模块的网络包后， 先立即回一个响应给主调模块， 然后做自己的事情。
从去年到今年， 一直有个告警， 差不多每两个星期会遇到一次， 主调的log显示， 调用被调机器时超时， 而且每次根据log分析， 都是集中在某一台被调机器上。 于是， 每次都以为是机器本身的原因， 于是找运维同学， 替换掉被调机器， 问题得到暂时解决。 后来发现， 即使不处理， 这个问题也会自己解决（实际是oom导致进程重启所致， 后续再表）
后来， 操作系统组的同学和运维同学怀疑是内核泄露(他们说不是业务代码的内存泄露)导致oom， 最后也没有确定的结论。
后来呢？ 被调模块的6台机器要缩容， 原来的问题就加剧了， 并且频繁发生。
最开始以为是主调的time wait太多（大约10000个）， 全方位降time wait, 但问题得不到解决。而且被调是直接立即回包的， 按道理说， 不应该存在慢的情况， 几乎就确定是主调的问题了。
后来摸索了很久， 去看被调模块， 发现内存异常。 某哥怀疑内存泄露， 并且内存泄露能解释遇到的所有现象， 而且信息显示确实oom了。 原来， 在内存吃紧的情况下， 即使是立即回包， 也可能很慢很慢。
我部署
最低0.47元/天 解锁文章
258
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
