【導語】在實際運維中，經常會遇到這樣的情況。 虛擬化平臺ESXi主機的化學CPU和顯存使用率低，部分用戶仍感覺速度慢。 虛擬化平臺看到的ESXi主機CPU占用率的參考值是多少？ 或者有什么具體的參考價值？ 本文將帶你繞過這些ESXi主機CPU使用的“坑”，讓你真正了解虛擬化平臺的CPU是否出問題，平臺性能是否良好。 請記住，有時眼見為實。
[作者] ID：，《深度運維》原作者
說到CPU的使用率，就不得不考慮這個參數了。 這個參數可能欺騙了很多虛擬化管理員。 言歸正傳，開始正文。 參數“”有點模棱兩可。 你很容易理解，“”指的是可以使用多少空閑的CPU。 “”越多越好。 然而，事實恰恰相反，越是“”，你的虛擬化平臺的性能就越差。
的值是指虛擬機準備就緒但未能獲得數學 CPU 調度的時間比率。 值越大，表示越多的虛擬機（或應用程序）在運行，沒有可用的CPU資源運行物理機轉換成vm虛擬機，這樣的虛擬機（或應用程序）只能等待CPU資源。
1、高的原因有哪些？
CPU占用率高的原因比較好找，的原因真的很難想。
其實高的原因主要有兩個，一是CPU嚴重過度分配，二是設置了CPU限制。
CPU 超額認購
主要原因是數學 CPU 中運行的活動虛擬 CPU (vCPU) 過多。 一般來說，分配比 pCPU 多的 vCPU 是正常且安全的，如果這個百分比很高，ESXi 調度程序就越難在不影響性能的情況下執行其任務。 當vCPU/pCPU的百分比為最佳CPU性能時，沒有一刀切的法則，有一些指導性參數可供參考：
CPU 限制
除非在少數特定場景下使用 CPU 限制，否則通常不設置 CPU 限制。 如果在虛擬機資源設置中設置了CPU限制，當虛擬機耗盡其分配的CPU資源時，系統將有意保留該虛擬機，避免將其調度到PCPU。 無論 CPU 使用率如何，都會出現此問題。 在命令的輸出中，有一個參數%MLMTD，表示虛擬機打算執行但由于有意限制還沒有調度CPU時間的時間量。 因為如果運行起來，就會違反資源池、虛擬機或環境的限制設置。 這句話是不是有點繞，雖然是說如果設置了CPU限制，即使化學CPU空閑，也不會把資源分配給受限的虛擬機。 默認情況下，虛擬機資源限制級別比較高，所以即使有閑置資源，也不會違反限制規則。 通常 %MLMTD 的值應為 0.000%。 在大多數情況下，不需要指定限制。 如果指定了限制，可能會浪費空閑資源。 右圖是在虛擬機上設置資源限制的形式。
CPU親和力
CPU親和性的目的是去除一些調度的靈活性，可以防止不同數學CPU之間的線程切換導致的緩存失效，提高緩存命中率，增強虛擬機的性能。 在虛擬機上設置 CPU 親和力永遠不會提高該虛擬機的 CPU 性能。 CPU 親和性的另一個問題是禁用，CPU 親和性是 ESXi 服務器為虛擬機手動指定特定內核的地方。 由于這種化學反應，內核無法在具有 CPU 親和力的主機之間進行通信，也無法在必須在此內核上運行的 VM 之間進行通信。 這對分布式資源調度 (DRS) 集群有重大影響。
FT 通過創建和維護與此虛擬機相同且可以在發生故障轉移時隨時更換的其他虛擬機來確保此類虛擬機的持續可用性。 受保護的虛擬機稱為主虛擬機。 在其他主機上創建并運行重復的虛擬機，稱為輔助虛擬機。 主虛擬機不斷復制到次虛擬機，使次虛擬機可以隨時接管工作，從而提供故障保護。 主虛擬機和輔助虛擬機持續監控彼此的狀態以確保故障得到維護。 如果運行主虛擬機的主機發生故障，系統將執行透明故障轉移。 此時會立即激活次虛擬機來代替主虛擬機，啟動新的次虛擬機，并手動重建故障冗余。 如果運行輔助虛擬機的主機發生故障，該主機也會立即被替換。 在任何一種情況下，用戶都不會遭受服務中斷和數據丟失。
如果FT的兩臺虛擬機之間的網絡出現問題，時不時兩臺虛擬機之間的信息無法同步，那么CPU的性能就會提升來維持兩臺虛擬機之間的同步。 最佳做法是在兩個虛擬機之間使用專用的高帶寬網絡。 它們之間的網絡類似于racs之間的脈沖，脈沖網絡尤為重要。 如果脈沖網絡出現問題，將直接影響性能。
2. 常見的誤區
有幾種常見的誤解，其中之一是超線程對性能的影響。 ESXi 調度程序將啟用超線程的 CPU 視為完整核心，但超線程核心無法提供 100% 的性能。 通常，啟用超線程的 CPU 只能提供真正化學 CPU 的 75% 的性能。 在啟用超線程的 CPU 上估算超額率需要保守，不能按 100% 進行估算。 規劃虛擬化平臺資源時也應注意這一點。
二是有很多可用或GHz并不一定意味著你的平臺沒有問題。
活躍的 CPU 使用量不能涵蓋一個虛擬機使用了多少核，也不能阻止其他虛擬機在特定時間段內使用它。 同樣，虛擬機的CPU使用率和值也不一定正確。 虛擬機可能很嚴重，CPU使用率確實不高，所以為了更準確的了解CPU的具體情況，需要從中關注所有CPU的使用率和全球視野。
還有一個問題是啟用DRS可以減少嗎？ 實際上DRS并不能減少，因為DRS沒有考慮CPU調度。 DRS只是通過監控CPU和顯存的使用情況來決定是否需要遷移，并沒有考慮vCPU和pCPU之間的爭用。
3、如何查看的值？
檢查環境中有多少是非常簡單的。 選擇要查看的主機，選擇性能，然后在圖表選項中選擇就緒，就可以看到當前的值。
但是從上圖可以看出的實際值。 該值是所有虛擬機上所有 vCPU 的總和。 很難針對不同的主機和不同的環境確認具體的值來判斷當前環境的是否有問題。 事實上，這個值在不同平臺之間差異很大，很難確定哪個平臺的性能最好。 所以你聽到的值基本上是沒有意義的。
使用基礎輸出之上的 %RDY 值以獲得更好的判斷。 但是，還需要考慮分配給每個虛擬機的vCPU數量，下一章會詳細說明這個值的具體含義。
4. 的正常值是多少？
我們很容易看到CPU占用率，很難根據看出平臺的CPU占用率是正常還是異常。
之前的版本官方建議每個vCPU的值要高于5%。 最新版本官方說只要CPU就緒時間小于10%就應該檢測主機是否過載，或者是否真的需要分配虛擬機。 所有資源。
如上圖，這里要注意，最后看到的值是每20s的數據，的度量單位是ms。 的估計方法是用20s減去某一時刻得到的值。 上圖中某時刻看到的值為5876，雖然這是20s內的數據，但是用5876/20000=0.29就是29%，是參考值5%的6倍，將近3 10%的倍數。 但此時化工機的CPU使用率只有7%。 從表面上看，Chem CPU 似乎處于正常狀態，此時平臺的 CPU 已經出現了嚴重的問題。
更詳細地說，客戶端看到的性能圖標中的默認時間間隔如下：
實時：20秒
最后三天：5 分鐘（300 秒）
上周：30 分鐘（1800 秒）
過去一個月：2 小時（7200 秒）
過去一年：1 天（86400 秒）
估計 比率
要按總值估算比率，請使用以下公式：
(CPU總值/(*1000)) 100=比率
例如：
一個虛擬機中一個虛擬機的實時統計可能有一個平均總值1000，用對應的值根據公式求出比率。
(1000/(20 秒*1000)) 100=5%
估計總 CPU 就緒值
要將比率轉換為總值，請使用以下公式進行反向估算：
(CPU就緒率/100) 1000=CPU總值
例如：
如果虛擬機的比率為 5，則其在實時性能圖表上的總 值估計如下：
(5/100)*20秒*1000=就緒
5、解決的方法有哪些？
A。 在每臺主機上部署合理數量的虛擬機
b. 確保 pCPU 沒有被 vCPU 過度分配太多。 如果CPU確實超配，應該根據實際情況減少化學引擎。
C。 不要使用CPU限制，CPU限制只適用于短期測試或問題分析
d. 不要使用CPU親和性規則，CPU親和性只適用于短期測試或問題分析
e. 使用故障（FT）時，必須使用最佳配置，尤其是在網絡中
F。 確認 DRS 做什么和不做什么以及不能減少什么 DRS
6.總結
在維護虛擬化平臺的過程中，不要輕易相信任何參數物理機轉換成vm虛擬機，尤其是你聽到的CPU使用率這個大“坑”，否則你可能已經入“坑”了，你可能會處在一個糟糕的境地坑。 再次指出，眼見不一定為實。 不要輕易下定論。 你應該一起判斷多個參數。 您可以深入了解平臺的性能。 最后祝大家好運，不要掉“坑”。
*免責聲明：本文基于作者自身理解創作，具體環境詳談。
原標題：防止平臺ESXi主機CPU占用的“坑”