诊断虚拟机频繁 OOM 的问题
前言
虚拟机被 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
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
面对您描述的虚拟机在OpenStack平台上频繁遭遇OOM（Out of Memory）的问题，您的问题定位和解决方案已经很到位了。这里我补充一些基于阿里云产品的建议，帮助优化和避免类似情况：
1. 使用ECS（Elastic Compute Service）
如果您考虑迁移到或与阿里云对接，ECS服务提供了强大的计算能力，并且阿里云平台对资源管理进行了深度优化，减少了因内存超卖或配置不当导致的OOM问题。
2. 实例规格选择与自动弹性伸缩
- 实例规格：在阿里云上，您可以根据业务需求选择不同系列的ECS实例，比如通用型、计算型、内存型等，确保实例规格与应用内存需求相匹配。
- 弹性伸缩：利用阿里云的弹性伸缩服务（Auto Scaling），可以根据预设策略自动增加或减少ECS实例数量，以应对突发的内存需求高峰，有效防止OOM。
3. 内存优化型实例
对于内存敏感型应用，可以考虑使用阿里云的内存优化型实例，这些实例设计时特别注重内存性能和容量，适合大数据处理、内存数据库等场景，能更好地满足高内存利用率的需求。
4. 阿里云容器服务ACK
如果您的应用适合容器化部署，可以考虑使用阿里云容器服务ACK（Alibaba Cloud Container Service for Kubernetes）。容器服务通过Kubernetes集群管理，能够更细粒度地控制资源分配，包括内存限制与请求，以及自动化的资源调度，有效避免单个应用影响整个节点的稳定性。
5. 监控与报警
利用阿里云的云监控服务，设置内存使用率的阈值报警，当接近危险水平时提前收到通知，及时进行资源调整或优化，预防OOM发生。
6. Swap配置
虽然在阿里云ECS中直接调整swap空间不如在自建环境中灵活，但可以通过挂载额外的数据盘并创建swap文件来间接实现。不过，增加swap只是缓解措施，根本解决还是在于合理规划内存使用和实例规格选择。
综上所述，结合阿里云的产品和服务，可以从多个维度出发，不仅解决当前的OOM问题，还能提升整体系统的稳定性和扩展性。
