容器OOM问题排查思路

序言

    又是一个冬季，在这寒冷的冬季，总是让人心动。。。迷雾之城

    外界的刁难，挑战。。。其实并不是最难的，最难的总是内部难以安抚，OOM。。。内存泄漏，OOM killer了解一下。。。攘外必先安内。。。我可能要死在内部了。。。

    抛出一个问题：容器是否需要限制内存的使用，限制CPU的使用呢？

OOM排查

    背景：

            微服务架构，几百个服务，运行在不同的容器上，总是莫名的同时出现十几个服务不可用，伴随着各个容器的状态异常，无法ping通，无法ssh上去，大量告警。。。总是莫名的有物理机宕机，每次查的时候总是无疾而终。。。

    

    验尸报告：

        Emmm，故障现场不够新鲜，检查的力度不够。。。

    故障之间总是有关联的，查出根本的问题之后，就发现，莫名的物理机宕机和这次发生的问题是一样的，只是原来从来没有想过，内存泄漏导致物理机重启，未曾进行关联，当查出每次都是OOM之后，那么问题就可以联系在一起，其实两者的问题的本质是一样的。

    收到告警，大量服务出现单点，查看相关的告警信息，大量的容器无法ping通，伴随着load值告警，而且这些所有的容器都分布在一台物理机上，有部门的服务在慢慢的恢复。。。经常看到这种情况的发生，也麻木了，等一会儿，慢慢就会自动恢复的。。。

    等了两个多小时，还没有恢复，依据以往的经验，这个时候应该已经恢复了。。。Emmm，经验往往是不可靠的，所谓的黑天鹅事件了解一下。。。