霍明明 360云计算
女主宣言
本文作者霍明明负责 360 HULK 云平台虚拟化和容器化服务的技术布道和解决方案推广等工作。本文主要探究的 OOM Killer 是一个内核功能，当宿主机内存不足时，会使用一系列启发式技术来选择杀死一个进程。本文最先发布于 opsdev, 转载已获取作者授权。
PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！
前言
虚拟机被 OOM 应该是运维 Iaas 平台人员经常会遇到的一个问题。这不，前段时间我们就遇到了某几个业务的虚拟机频繁被 OOM 的情况，我们来看一下是什么原因。
场景描述：
Iaas 管理平台： OpenStack
计算节点： CentOS7.2、QEMU、KVM、128GB内存
1
问题定位
现象是业务虚拟机非人为宕机，且运行一段时间就会发生。在查看操作历史和审计记录确认不是人为操作后，通过计算节点系统日志发现，是系统内存不足触发 OOM 导致。
原因是找到了，但是发现比较诡异，为什么呢？
首先，这些虚拟机所在的计算节点并没有开启内存超卖；
其次，我们已经给计算节点 OS 预留了 12GB 的内存（12GB / 128GB = 9.375%）。也就是说撑死了虚拟机使用内存，所有虚拟机内存使用总量也不会超过总内存的 100% - 9.375% = 90.625%，按照这个理论值计算的话，除非 OS 的内存使用量非常大，否则不应该有 OOM 情况的发生。
2
问题排查
经验上来说，计算节点 OS 上跑的服务内存不会吃满 12GB, 除非是某些服务出现内存泄露的情况。带着疑问，我们将被 OOM 的虚拟机重新启动，在宿主机上观察内存使用情况。
经过一段时间的运行后虚拟机还是被 OOM 掉了，但是 OS 上的服务并没有内存泄露等情况，且总内存使用量也很正常，大约在 4GB 左右。此时，理论内存最大使用率约为 (128 - 12 + 4) / 128 = 93.75%，此时，系统不应该触发 OOM，这还不算 swap (4GB). 这里，我们排除了计算节点 OS 内存使用问题导致的 OOM.
既然，OS 内存使用没问题，那么换个角度看看虚拟机内存使用是否有问题呢？
通过对计算节点上触发 OOM 前后虚拟机进程 (qemu-kvm) 分配的内存进行统计，发现了一个“大”问题。
如上图，RES 一列，内存的使用量远大约分配给虚拟机的内存量。套餐是 4核8GB 的虚拟机内存实际使用量基本在 8.3 ~ 8.9GB 之间，套餐是 2核4GB 的虚拟机内存实际使用量也基本在 4.6 ~ 4.8GB 之间。至此，我们知道了多出来的内存被谁使用了。
为什么虚拟机内存使用量会比分配的值要大呢？到虚拟机内部去看，其内存使用虽然很满，但是没有达到超过分配值的情况。
带着疑问，Google 了一些资料，其他人也有类似的疑惑。
https://lime-technology.com/forums/topic/48093-kvm-memory-leakingoverhead/
文章的意思是说除了虚拟机内部使用的内存外，qemu-kvm 进程还需要为虚拟的设备提供内存，这部分内存也算在了虚拟机进程 qemu-kvm 头上了。
问题我们定位了，那如何解决这个问题，减少虚拟机被 OOM 情况发生呢？
3
解决方案
增大 OS 预留内存空间。通过增大 OS 预留内存空间来填充虚拟机膨胀部分内存，使得总体内存使用率不会超过 OOM 的临界值。
调大 swap 值。目前我们计算节点 swap 值统一为 4GB，对于一个 128GB 内存的节点来说 4GB 内存有点小。我们发现在虚拟机 OOM 时，swap 使用率肯定是 100%，这也很符合 OOM 产生的前提条件。所以，如果你的节点上有 SSD 盘的话，建议将 swap 适当调大。
修改 OpenStack 逻辑，在虚拟机调度内存计算时，比套餐值大一些，给虚拟机预留出膨胀部分内存。不过这种方式不太通用，不建议使用。
“
参考文献：
1.https://lime-technology.com/forums/topic/48093-kvm-memory-leakingoverhead/
2.https://unix.stackexchange.com/questions/140322/kvm-killed-by-oomkiller