前言
虚拟机被 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 情况的发生。
带着疑问,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 逻辑,在虚拟机调度内存计算时,比套餐值大一些,给虚拟机预留出膨胀部分内存。不过这种方式不太通用,不建议使用。
更多IT资讯就上CloudCare app