某次压测时物理内存被用光 Tomcat 被 Kernel kill 掉的案例

背景描述

某项目结构图如下(前端交互式体验及对象存储为主，Redis 及 rds 负载较小没有画出)：

web1 和 web2 是两个 Apache，publisher1 和 publisher2 是两个 Tomcat 容器下的 app 应用服务器。

在对该项目进行压测时，并发数加到 750 左右，阿里云 PTS 压测工具监测到在某个时间点后 tps 呈下降趋势：

作为对应指标的响应时间(rt)在这个时间点呈上升趋势：

查看实时监控-监控集指标，发现 publisher1 节点的 CPU 利用率已降为 1.9，在高并发的时候这个值肯定是有问题，很可能这个节点已经宕掉:

查看网络流量发现该节点果然已经没有了网络流量：

ssh 登录 publisher1 ps 证实 Tomcat 确实已经 crash。但查 Tomcat 日志、应用日志，没有任何异常，find 也没找到类似于 hs_err_pidNNN.log 之类的 crash 日志。Tomcat 内存分配情况： JAVA_OPTS="-Xmx3072m"

系统物理内存 8G，看上去绰绰有余。真的是这样吗？

原因分析

一般来讲，诸如内存溢出之类常见的 Tomcat 崩溃都会在容器日志或者 crash 日志中记录原因。但不排除这种情况：Linux 允许系统中的进程申请比现有系统可用内存还要多的内存，但当整个系统内存不足的时候，Kernel 会将耗用内存最多的那个进程给干掉，就是 Tomcat 了，但这并不能说明 Tomcat 发生了某些运行时的致命错误，所以我们没有看到任何容器、应用甚至 jvm 级别的异常，Tomcat 来不及做任何日志处理就 Over 了。 查看 /var/log/message，在 PTS 指示的时间点找到了以下日志：

注意以上系统时间为 UTC 时间，对应北京时间为 Jul 25 11:15:39，PTS 监控到的 publisher1 节点的内存曲线图的顶点跟 OOM 的时间也基本一致：

可以看到在 11:15 左右 publisher1 节点的 8G 物理内存已经用光。

解决方案

当 Linux 系统物理内存不够用的时候，需要将物理内存中的一部分空间释放出来以供当前运行程序使用。这些被释放出来的空间很可能来自于一些长时间没有什么操作的程序，这些被释放出来的空间会被临时存放到 SWAP 空间，等这些程序要运行时，再从 SWAP 恢复数据到内存。上述案例 publisher1 节点 SWAP 查看：

交换分区空间没有，系统在物理内存不够的时候也就没有临时空间可以利用，为了整个系统的正常运行，"oom_killer" 函数被调用了，于是 Tomcat 悲剧了。。。

解决方案似乎已经很明显了。值得一提的是，在上面的 message 日志里，Kernel 在筛选要干掉的进程的日志里，在其前面紧挨着的便是指示 SWAP 为 0 无交换空间可用:)

参考资料

Tomcat stopped without any log or any stack Out of Memory + httpd.worker invoked oom-killer

博主 20170727 日续：关于 Apache 的类似案例

上述案例中 app 节点，也就是 publisher1 节点修复以后，继续加压测试，在并发数达到 1000 的时候，web2 节点宕掉。具体表象为 web2 服务器 SSH 连不上，阿里云 PTS 监控集也显示为 web2 处于下线状态。

查看 web2 的 /var/log/message，该时间段日志摘要如下：

日志处理逻辑看上去和 publisher1 干掉 Tomcat 的做法一般无二，区别在于 Apache 为了保证高可用性在 httpd worker 进程故障后会再拉起一个，系统物理内存最终被耗光而 OOME 宕机。于是 Publisher1 的表象为 Tomcat 的 crash，而 web2 的表象为 Linux 系统无响应。

解决办法是，除了像 publisher1 那样给 web2 启用虚拟空间，还可以降低 Apache 的最大连接数 MaxClients、最大内存 ServerLimit，修改后使用命令 service httpd restart 对 apache 进行重启使配置生效。

作者：Defonds 来源：http://blog.csdn.net/defonds/article/details/76070281