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.

0?wx_fmt=png
既然，OS 內存使用沒問題，那麽換個角度看看虛擬機內存使用是否有問題呢？

通過對計算節點上觸發 OOM 前後虛擬機進程 (qemu-kvm) 分配的內存進行統計，發現了一個“大”問題。

如上圖，RES 一列，內存的使用量遠大約分配給虛擬機的內存量。套餐是 4核8GB 的虛擬機內存實際使用量基本在 8.3 ~ 8.9GB 之間，套餐是 2核4GB 的虛擬機內存實際使用量也基本在 4.6 ~ 4.8GB 之間。至此，我們知道了多出來的內存被誰使用了。

為什麽虛擬機內存使用量會比分配的值要大呢？到虛擬機內部去看，其內存使用雖然很滿，但是沒有達到超過分配值的情況。

0?wx_fmt=png
帶著疑問，Google 了一些資料，其他人也有類似的疑惑。

https:/h5.hxforum.com

文章的意思是說除了虛擬機內部使用的內存外，qemu-kvm 進程還需要為虛擬的設備提供內存，這部分內存也算在了虛擬機進程 qemu-kvm 頭上了。

問題我們定位了，那如何解決這個問題，減少虛擬機被 OOM 情況發生呢？

3

解決方案

增大 OS 預留內存空間。通過增大 OS 預留內存空間來填充虛擬機膨脹部分內存，使得總體內存使用率不會超過 OOM 的臨界值。

調大 swap 值。目前我們計算節點 swap 值統一為 4GB，對於一個 128GB 內存的節點來說 4GB 內存有點小。我們發現在虛擬機 OOM 時，swap 使用率肯定是 100%，這也很符合 OOM 產生的前提條件。所以，如果你的節點上有 SSD 盤的話，建議將 swap 適當調大。

修改 OpenStack 邏輯，在虛擬機調度內存計算時，比套餐值大一些，給虛擬機預留出膨脹部分內存。不過這種方式不太通用，不建議使用。

微信h5鳳凰十人大廳系統出售診斷虛擬機頻繁 OOM 的問題