docker OOM问题排查思路

OOM排查
背景：

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

验尸报告：

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

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

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

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

大量的容器无法ping通，登录上主机，查看资源抢占情况*（示例图）：

在以上的图中，主要看四个指标，一个是load，Emmm，假设CPU是56个，实际的load值达到了3K，那么这个时候，系统已经不堪重负了；一个是Tasks，主要看任务的运行数量，在图中，才2个在运行，实际也就几百个，但是sleeping状态的有几万个，而zombie状态的有300多个；一个就是内存的使用量，在实际情况中，内存基本使用完毕；最后一个就是使用交换空间，图中的未使用，实际上已经全部使用完毕。

系统资源不足，要不扩容试试。。。向上？还是水平扩展。。。Emm，当然是不可能的。。。

CPU的load太高，那么说起来其实也就两个队列，一个是运行的队列，一个block的队列，从而需要收集相关的进程信息，从而可以使用ps来查看进程的状态信息：

以上主要是为了统计：一个是进程的数量，一个是线程的数量。。。（需要多次执行，从而进行对比，可以知道哪些进程造成了相关的阻塞，数量庞大的必有蹊跷。。），统计的结果是大量状态为D的进程。。。在线程多的结果中，可以看到相关的PID，从而可以知道是哪个进程产生了大量的阻塞。。。

统计容器的数量，从容器的内存限制来查看是否容器的内存都达到了限制。

在查看结果的时候，发现很多容器使用的内存值和限制值差不多一致，而且falcnt也就是分页中断有几万次。。。当然缺页异常几万次，可能或许maybe属于正常情况。。

保存进程列表（主要是保存进程的树形结构，可以用来追查父进程）：

突然出现。。。fork，Can't allocate memory!。。至此已经无法查看相关信息，只能。。。重启服务器了。。。所有的内存已经耗尽。。。。

重启之后查看相关的日志：对。。。重启是万能的。。。

在日志里面查看到大量的OOM信息，也就可以看到相关的进程被杀死，从而可以找到是哪些进程导致了内存泄漏，从而进行整改。。。在kern日志中可以看到被杀死的进程名，在dmesg中可以看到OOM，在message中，能追查到相关的容器id。。。

排查思路：根据load值偏高，查询进程的数量和线程的数量，从而从增加的数量查看到是什么样的进程阻塞了CPU的调度，查看系统日志，主要查看oom，从而对比两者的结果进程是否一致，从而看哪个进程OOM需要整改。。。可能你会说，查看单独进程的内存占用量，Emmm，这也是一个排查思路。。。

风言风语
在以上的问题追踪中，可以产生两个疑点：第一既然oom都杀死了进程，为什么内存还会溢出，杀死了进程应该已经将相关的内存进行回收了；第二：是什么导致了那么高的load值。。。

回答第一个问题就是：在oom killer进行杀死进程的时候，使用的是kill -9 ，从而能强行杀死进程，但是在进行oom的时候，oom的分值是给占用内存大的进程，而这个进程在等待IO，也就是等待分配内存，Emm。。。读取内存也是一种IO，所谓的缺页中断。。。在杀死这个进程的时候，这个进程的状态为D，也就是表示这个进程是不可中断睡眠，在等待分配内存。。。从而杀死这个进程可能根本就无法杀死。。。

还有一种情况是，进程已经变成了僵尸进程，从而在oom killer在进行杀死进程的时候，根据当前的进程号id杀，而僵尸进程要想杀死，必须杀掉其父进程，而当僵尸进程的父进程为1的时候，这个时候就相当于服务器重启了。

回答第二个问题就是：将一个进程杀死，变成了僵尸进程，自动拉起进程并不能识别变成了僵尸进程，从而会自动拉起服务，然后又内存溢出，再次杀，再次变成僵尸进程，死循环，最终导致内存耗尽。。。

还有一种情况就是，在容器中运行了很多进程，而oom分值高的进程是其中的一个子进程，而不是容器的根进程，也就是pid为1的进程，如果恰好是1的进程，那么很完美，相当于将容器进行重启，那么这种情况下会慢慢的恢复，不会增加load值；而当是一个普通进程之后，杀掉，有很大的概率变成僵尸进程。。。

容器也是一个进程，在其中又有很多进程，资源隔离还不是那么好。。。原因之一也在于使用不当。

最后解答开篇的问题：要不要设置cpu和容器的最高使用值。。。要

如果在容器的层面进行限制了内存的使用，那么就只有容器出现OOM，而不会影响这台机器上其他的容器，不会出现资源竞争的情况。。。在查看容器oom的时候，也可以通过docker inspect id来查看容器的OOM。。。

docker OOM问题排查思路相关推荐

生产docker run 卡住没反应故障排查思路
参考文献: docker run hangs问题排查记录 https://www.cnblogs.com/edenlong/p/10972876.html 阿里巴巴 Kubernetes 集群问题排查 ...
IT故障排查思路和方法交流
1.故障处理原则首要原则: 生产环境优先恢复业务(比如重启服务.修改负载均衡指向.恢复原有程序包等):保留现场以备查找故障原因 a.遇到问题不要慌:理清思路: b.首先要自行排查,不要遇到问题就甩到 ...
Java线上问题排查思路及Linux常用问题分析命令学习
前言之前线上有过一两次OOM的问题,但是每次定位问题都有点手足无措的感觉,刚好利用星期天,以测试环境为模版来学习一下Linux常用的几个排查问题的命令. 也可以帮助自己在以后的工作中快速的排查线上问 ...
curl命令java_让 Bug 无处藏身，Java 线上问题排查思路、常用工具
本文总结了一些常见的线上应急现象和对应排查步骤和工具.分享的主要目的是想让对线上问题接触少的同学有个预先认知,免得在遇到实际问题时手忙脚乱. 只不过这里先提示一下.在线上应急过程中要记住,只有一个总体 ...
Java 线上问题排查思路与工具使用
本文来自作者蓬蒿在 GitChat 上分享「Java 线上问题排查思路与工具使用」,「阅读原文」查看交流实录. 「文末高能」编辑 | 哈比一.前言 Java 语言是当前互联网应用最为广泛的语 ...
K8S集群中Pod与Pod之间网络故障排查思路
K8S集群中Pod与Pod之间网络故障排查思路文章目录 K8S集群中Pod与Pod之间网络故障排查思路 1.Pod与Pod之间通信故障 2.Pod与Pod之间网络通信故障排查思路 1.Pod与Pod ...
线上Java 高CPU占用、高内存占用排查思路
一.前言处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题.当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警.本文主要针对系统 ...
线上问题排查思路总结
前言: 本文总结一些常见的线上问题和对应的排查思路,工具.对于线上问题,我们必须记住一个原则:尽快恢复服务,消除影响.不管出于应急的哪个阶段,我们首先必须想到的是恢复问题,恢复问题并不意味着必须在当下 ...
系统运行缓慢，CPU 100%，以及Full GC次数过多问题的排查思路
点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试资料来源:http://h5ip.cn/uWWR 处理过线上问题的同学 ...

docker OOM问题排查思路

docker OOM问题排查思路相关推荐

最新文章

热门文章