☰

在 VMware 中多少爭用才算過多？

tag-icon • tag-icon virtualization memory vmware-vsphere
在 VMware 中多少爭用才算過多？

一段時間以來，我一直試圖弄清楚為什麼我們的許多關鍵業務系統都會收到從輕微到極端的「緩慢」報告。我最近將目光轉向了託管所有相關伺服器的 VMware 環境。

我最近下載並安裝了 SCOM 2012 的 Veeam VMware 管理套件試用版，但我很難相信（我的老闆也是如此）它向我報告的數字。為了讓我的老闆相信它告訴我的數字是真的，我開始研究 VMware 用戶端本身以驗證結果。

我看過這篇 VMware 知識庫文章;特別針對 Co-Stop 的定義，其定義為：

MP 虛擬機器準備運作但由於協同 vCPU 調度爭用而導致延遲的時間量

我正在翻譯成

來賓作業系統需要主機的時間，但必須等待資源變得可用，因此可以被視為“無回應”

這個翻譯看起來正確嗎？

如果是這樣，我很難相信我所看到的：包含大多數「慢」虛擬機器的主機目前顯示的 CPU Co-stop 平均值為127,835.94毫秒！

這是否意味著該主機上的虛擬機器平均需要等待 2 分鐘以上的 CPU 時間？

該主機上確實有兩個 4 核心 CPU，並且有 1x8 CPU 來賓和 14x4 CPU 來賓。

答案1

我可以描述我在這個領域的一些經驗...

我認為 VMware 在教育客戶方面做得不夠（或管理員）關於最佳實踐，他們也不會隨著產品的發展而更新以前的最佳實踐。這個問題是一個如何不完全理解 vCPU 分配等核心概念的範例。最好的方法是從小規模開始，使用單一 vCPU，直到您確定虛擬機器需要更多。

對於 OP，ESXi 主機伺服器有兩個四核心 CPU，產生 8 個實體核心。

所描述的虛擬機器佈局總共有 15 個來賓； 1 x 8 vCPU 和 14 x 4 vCPU 系統。這太過分了，尤其是存在具有 8 個 vCPU 的單一來賓。這個不成立。如果您需要這麼大的虛擬機，您可能需要更大的伺服器。

請嘗試合適的尺碼你的虛擬機器。我非常確定他們中的大多數人都可以使用 2 個 vCPU。新增虛擬 CPU 並不會讓系統運作得更快，因此，如果這是解決效能問題的方法，那麼這種方法是錯誤的。

在大多數環境中，RAM 是最受限的資源。但如果爭用過多，CPU 可能會成為問題。你有證據證明這一點。如果出現以下情況，RAM 也可能是個問題：分配給各個虛擬機器的資源太多。

這是可以監控的。您要找的指標是「CPU Ready %」。您可以從 vSphere 用戶端存取此信息，方法是選擇虛擬機器並轉到Performance> Overview> CPU 圖表。

  • CPU 就緒率低於 5%- 你沒事。
  • 5-10% CPU 就緒- 密切注意活動。
  • 超過 10% CPU 就緒- 不好。

請注意下圖中的黃線。 在此輸入影像描述

您介意在有問題的虛擬機器上檢查並報告嗎？

答案2

您在評論中聲明您擁有一台雙四核心 ESXi 主機，並且正在執行 8vCPU 虛擬機，並且十四4vCPU 虛擬機器。

如果這是我的環境，我會認為這是嚴重地過度配置。我最多會在該硬體上放置四到六個 4vCPU 來賓。 （這是假設相關虛擬機器的負載要求它們具有如此高的 vCPU 數量。）

我假設您不知道黃金法則……對於VMware，您永遠不應該為虛擬機器分配超過其需要的核心。原因？ VMware 使用較嚴格的聯合調度，這使得虛擬機器很難獲得 CPU 時間，除非有與分配給虛擬機器一樣多的可用核心。這意味著，除非同時開啟 4 個實體核心，否則 4vCPU 虛擬機器無法執行 1 個工作單元。換句話說，從架構上來說，擁有 90% CPU 負載的 1vCPU 虛擬機器比擁有每核心 45% 負載的 2vCPU 虛擬機器更好。

因此...始終建立具有最少 vCPU 的虛擬機，並且僅在確定有必要時添加它們。

根據您的情況，請使用 Veeam 監控虛擬機器上的 CPU 使用情況。盡可能減少 vCPU 計數。我敢打賭，您幾乎可以在所有現有的 4vCPU 客戶機上降低到 2vCPU。

當然，如果所有這些虛擬機器實際上都有 CPU 負載來需要它們擁有的 vCPU 數量，那麼您只需購買額外的硬體即可。

答案3

127,835.94 毫秒是一個總和，您需要除以取樣時間才能獲得正確的 %RDY 值。不過，看起來您現在已經獲得了正確的 %RDY 讀數。您可以將 vCPU 與實體 CPU 的比率設定得相當高，但不能採用您的方式。

您擁有太多的四核心 vCPU 虛擬機，甚至是 8 核心 vCPU 虛擬機。一些品質響應已經討論了正確的規模以及不將週期整合到更少 vCPU 的一些後果。我確實想澄清的一件事是，雖然虛擬機不再需要等待實體 CPU 數量等於其 vCPU 數量才可用才能處理任何指令，但這是非常有害的以多vCPU 虛擬機與物理核心的比率實現如此大規模的過度配置。 8 個核心上的 64 個 vCPU 遠遠超出了 4 比 1 的最大比例。我假設這些處理器上有 HT，所以有 16 個邏輯核心？對於負載較輕的 1 個和 2 個 vCPU 虛擬機器來說，這可能沒問題，但如果虛擬機器負載較重，則很難實現。

僅供參考，CPU 使用百分比計算中不使用 HT 處理器 - 這意味著如果您的伺服器上有 32 個以 2.4 Ghz 運行的邏輯核心，那麼當您達到 38.4 GHz 時，您的使用率為 100%。因此，當您看到平均負載顯示超過 1.0 時，這就是原因。

這是一台運行 vCPU 與實體 CPU（包括 HT 核心）比率為 3.5 比 1 的 ESXi 主機，平均 %RDY 為 3%。

11:13:49pm up 125 days  7:20, 1322 worlds, 110 VMs, 110 vCPUs; CPU load average: 1.34, 1.43, 1.37


  %USED    %RUN    %SYS   %WAIT %VMWAIT    %RDY   %IDLE  %OVRLP   %CSTP  %MLMTD  %SWPWT 
  13.51   15.87    0.50  580.17    0.03    4.67   66.47    0.29    0.00    0.00    0.00 
  15.24   18.64    0.43  491.54    0.04    4.65   63.70    0.43    0.00    0.00    0.00 
  13.44   16.40    0.44  494.10    0.02    4.33   66.24    0.48    0.00    0.00    0.00 
  13.75   16.30    0.51  494.26    0.32    4.32   66.06    0.35    0.00    0.00    0.00 
  17.56   20.72    0.58  489.35    0.04    4.31   60.76    0.45    0.00    0.00    0.00 
  13.82   16.43    0.50  494.12    0.07    4.31   66.26    0.26    0.00    0.00    0.00 
  13.65   16.81    0.49  493.81    0.03    4.21   65.93    0.37    0.00    0.00    0.00 
  13.73   16.51    0.42  493.63    0.09    4.06   66.24    0.29    0.00    0.00    0.00 
  13.89   16.37    0.55  580.61    0.04    3.95   66.69    0.28    0.00    0.00    0.00 
  14.02   17.00    0.33  494.11    0.03    3.93   66.10    0.29    0.00    0.00    0.00 
  13.44   15.84    0.49  495.17    0.04    3.87   67.24    0.27    0.00    0.00    0.00 
  13.59   15.84    0.50  580.27    0.04    3.81   67.24    0.44    0.00    0.00    0.00 
  17.10   19.86    0.50  490.97    0.04    3.74   62.21    0.39    0.00    0.00    0.00 
  13.32   15.77    0.50  495.34    0.03    3.73   67.47    0.27    0.00    0.00    0.00 
  13.43   16.15    0.48  494.95    0.05    3.72   67.09    0.38    0.00    0.00    0.00 
  13.44   16.47    0.49  580.88    0.04    3.72   66.81    0.40    0.00    0.00    0.00 
  13.71   17.00    0.29  494.13    0.03    3.71   66.26    0.37    0.00    0.00    0.00 
  17.34   20.41    0.39  490.50    0.05    3.70   61.70    0.37    0.00    0.00    0.00 
  13.42   16.19    0.50  495.07    0.03    3.66   67.15    0.38    0.00    0.00    0.00 
  13.56   16.23    0.48  494.97    0.03    3.60   67.12    0.30    0.00    0.00    0.00 
  14.95   17.53    0.42  578.82    0.09    3.57   65.72    0.35    0.00    0.00    0.00 
  13.44   16.07    0.56  581.14    0.04    3.54   67.34    0.40    0.00    0.00    0.00 
  17.19   21.27    0.37  575.41    0.04    3.44   61.08    0.51    0.00    0.00    0.00 
  13.57   16.99    0.30  580.64    0.01    3.37   66.69    0.38    0.00    0.00    0.00 
  13.79   16.25    0.43  495.25    0.04    3.35   67.39    0.39    0.00    0.00    0.00 
  11.90   14.67    0.30  496.86    0.02    3.31   69.00    0.36    0.00    0.00    0.00 
  17.13   19.28    0.56  491.83    0.03    3.30   63.26    0.48    0.00    0.00    0.00 
  14.01   16.17    0.50  495.56    0.01    3.30   67.66    0.39    0.00    0.00    0.00 
  16.86   20.16    0.57  491.19    0.05    3.20   62.44    0.43    0.00    0.00    0.00 
  14.94   17.46    0.42  580.05    0.08    3.16   66.24    0.40    0.00    0.00    0.00 
  14.56   16.94    0.36  494.86    0.08    3.14   66.91    0.42    0.00    0.00    0.00

......

答案4

此後，我們安裝了 Veeam ONE，它清楚地揭示了我們的效能問題所在。透過查看 Veeam ONE 中的 CPU 瓶頸螢幕，然後使用對已停止回應的虛擬機器進行故障排除：VMM 和來賓 CPU 使用率比較作為參考，我們已經弄清楚了我們「不可接受」的論點的分配情況。

我想特別分享的一個小技巧是，在一種情況下，除非刪除虛擬機器上的快照，否則我無法消除 CPU 爭用。希望這對某人有幫助。

相關內容