如果您管理基於 VMware vSphere（或任何其他技術堆疊）的虛擬基礎架構，您可能經常聽到用戶抱怨：“虛擬機器速度很慢！” 在本系列文章中，我將分析效能指標，並告訴您它變慢的原因和原因，以及如何確保它不會變慢。
我會考慮虛擬機器效能的以下幾個方面：
- CPU，
- RAM，
- 磁碟,
- 服務據點
我將從CPU開始。
為了分析性能，我們需要：
- vCenter 效能計數器 – 效能計數器，可以透過 vSphere Client 查看其圖表。 有關這些計數器的資訊可在任何版本的用戶端中取得（C# 中的「厚」客戶端、Flex 中的 Web 用戶端和 HTML5 中的 Web 用戶端）。 在這些文章中，我們將使用 C# 客戶端的螢幕截圖，只是因為它們在縮小版中看起來更好:)
- ESXTOP – 從 ESXi 命令列執行的實用程式。 借助它的幫助，您可以即時獲取效能計數器的值，或將特定時間段內的這些值上傳到 .csv 檔案中以供進一步分析。 接下來，我將向您介紹有關此工具的更多信息，並提供一些指向有關該主題的文檔和文章的有用鏈接。
一點理論
在 ESXi 中，一個單獨的進程（VMware 術語中的世界）負責每個 vCPU（虛擬機器核心）的操作。 還有服務進程，但從分析VM效能的角度來看，它們不太有趣。
ESXi 中的進程可以處於以下四種狀態之一：
- 跑 – 流程執行一些有用的工作。
- 等待 – 進程未執行任何工作（空閒）或正在等待輸入/輸出。
- 科斯托普 – 多核心虛擬機器中出現的情況。 當管理程式 CPU 調度程式 (ESXi CPU Scheduler) 無法調度實體伺服器核心上所有活動虛擬機器核心的同時執行時，就會發生這種情況。 在實體世界中，所有處理器核心並行工作，VM 內的客戶作業系統期望類似的行為，因此虛擬機器管理程式必須減慢能夠更快完成時脈週期的 VM 核心的速度。 在現代版本的 ESXi 中，CPU 調度程式使用一種稱為寬鬆協同調度的機制：虛擬機器管理程式考慮「最快」和「最慢」虛擬機核心之間的差距（偏差）。 如果差距超過某個閾值，快速核心就會進入costop狀態。 如果 VM 核心在這種狀態下花費大量時間，則可能會導致效能問題。
- 各就各位 – 當管理程式無法為其執行指派資源時，進程就會進入此狀態。 高就緒值可能會導致VM效能問題。
基本虛擬機器 CPU 效能計數器
CPU使用率， ％。 顯示在給定時間內 CPU 使用率的百分比。
怎麼分析呢？ 如果虛擬機器的 CPU 使用率始終為 90%，或峰值高達 100%，那麼我們就會遇到問題。 問題不僅表現在虛擬機器內的應用程式運行“緩慢”，而且還表現在無法透過網路存取虛擬機器。 如果監控系統顯示VM週期性下降，請注意CPU使用率圖表中的峰值。
有一個標準警報顯示虛擬機器的 CPU 負載：
怎麼辦呢？ 如果虛擬機器的 CPU 使用率不斷飆升，那麼您可以考慮增加 vCPU 的數量（不幸的是，這並不總是有幫助）或將虛擬機器移至具有更強大處理器的伺服器。
CPU 使用率（MHz）
在 vCenter 使用率百分比圖表中，您只能看到整個虛擬機器的情況；沒有單一核心的圖表（在 Esxtop 中，有核心的 % 值）。 對於每個核心，您可以查看使用情況（以 MHz 為單位）。
怎麼分析呢？ 碰巧某個應用程式沒有針對多核心架構進行最佳化：它僅 100% 使用一個核心，其餘的在沒有負載的情況下閒置。 例如，使用預設備份設定時，MS SQL 僅在一個核心上啟動該進程。 結果，備份變慢並不是因為磁碟速度慢（這是用戶最初抱怨的），而是因為處理器無法應付。 透過更改參數解決了問題：備份開始在多個檔案中並行運行（分別在多個進程中）。
核心負載不均勻的範例。
還有一種情況（如上圖所示），核心負載不均勻，其中一些核心的峰值達到 100%。 和只載入一個核一樣，CPU使用率的警報不會起作用（是針對整個VM的），但會有效能問題。
怎麼辦呢？ 如果虛擬機器中的軟體對核心的負載不均勻（僅使用一個核心或部分核心），則增加其數量是沒有意義的。 在這種情況下，最好將虛擬機器遷移到具有更強大處理器的伺服器。
您也可以嘗試檢查伺服器 BIOS 中的功耗設定。 許多管理員在 BIOS 中啟用高效能模式，從而停用 C 狀態和 P 狀態節能技術。 現代英特爾處理器使用睿頻加速技術，該技術以犧牲其他核心為代價來提高單一處理器核心的頻率。 但它只有在節能技術開啟時才起作用。 如果我們停用它們，處理器將無法降低未載入核心的功耗。
VMware 建議不要停用伺服器上的節能技術，而是選擇盡可能將電源管理留給虛擬機器管理程式的模式。 在這種情況下，在虛擬機器管理程式功耗設定中，您需要選擇「高效能」。
如果您的基礎架構中有單一 VM（或 VM 核心）需要提高 CPU 頻率，則正確調整功耗可以顯著提高其效能。
CPU就緒
如果VM核心（vCPU）處於Ready狀態，則它不會執行有用的工作。 當管理程式找不到可以指派虛擬機器 vCPU 進程的空閒實體核心時，就會發生這種情況。
怎麼分析呢？ 通常，如果虛擬機器的核心處於就緒狀態的時間超過 10%，您就會注意到效能問題。 簡而言之，VM 有超過 10% 的時間等待實體資源變得可用。
在 vCenter 中，您可以查看 2 個與 CPU Ready 相關的計數器：
- 準備就緒，
- 準備。
可以查看整個 VM 和各個核心的兩個計數器的值。
就緒狀態立即以百分比形式顯示該值，但僅限於即時（最後一小時的數據，測量間隔 20 秒）。 最好僅使用此計數器來搜尋“緊跟其後”的問題。
就緒計數器值也可以從歷史角度查看。 這對於建立模式和更深入地分析問題很有用。 例如，如果虛擬機器在某個時間點開始出現效能問題，您可以將CPU Ready值的時間間隔與該虛擬機器運行的伺服器上的總負載進行比較，並採取措施降低負載（如果DRS失敗）。
與就緒狀態不同，就緒狀態不是以百分比顯示，而是以毫秒顯示。 這是一個求和型計數器，也就是它顯示在測量期間VM 核心處於就緒狀態的時間。 您可以使用簡單的公式將該值轉換為百分比：
(CPU 就緒總和值 / (圖表預設更新間隔（以秒為單位）* 1000)) * 100 = CPU 就緒%
例如，對於下圖中的虛擬機，整個虛擬機器的就緒峰值如下：
在計算Ready百分比時，需要注意兩點：
- 整個VM的Ready值是跨核心Ready的總和。
- 測量間隔。 對於實時，它是 20 秒，例如，在日線圖上，它是 300 秒。
透過主動故障排除，這些簡單的問題很容易被忽略，並且可能浪費寶貴的時間來解決不存在的問題。
讓我們根據下圖中的數據計算 Ready。 整個虛擬機器的 (324474/(20*1000))*100 = 1622%。 如果你看一下核心，那就沒那麼可怕了：1622/64 = 每個核心 25%。 在這種情況下，問題很容易被發現：Ready 值不切實際。 但如果我們討論的是具有多個核心的整個 VM 的 10-20%，那麼對於每個核心，該值可能在正常範圍內。
怎麼辦呢？ Ready 值較高表示伺服器沒有足夠的處理器資源來支援虛擬機器的正常運作。 在這種情況下，剩下的就是減少處理器（vCPU：pCPU）的超額訂閱。 顯然，這可以透過減少現有虛擬機器的參數或將部分虛擬機器遷移到其他伺服器來實現。
並站
怎麼分析呢？ 此計數器也是Summation類型，轉換為百分比的方式與Ready相同：
(CPU 同步停止總和值 / (圖表預設更新間隔（以秒為單位）* 1000)) * 100 = CPU 同步停止 %
這裡也需要注意VM上的核心數量和測量間隔。
在costop狀態下，核心不會執行有用的工作。 透過正確選擇虛擬機器大小和伺服器上的正常負載，同步停止計數器應接近零。
在這種情況下，負載明顯不正常:)
怎麼辦呢？ 如果多個具有大量核心的虛擬機器在一個虛擬機器管理程式上運行，且 CPU 超額訂閱，則 co-stop 計數器可能會增加，這將導致這些虛擬機器的效能出現問題。
此外，如果一台虛擬機器的活動核心使用啟用了超線程的實體伺服器核心上的線程，則 co-stop 也會增加。 例如，如果 VM 的核心數量多於其運行的伺服器上的物理可用核心數量，或者如果為 VM 啟用了「preferHT」設置，則可能會發生這種情況。 您可以閱讀有關此設定的信息 .
為了避免因高同步停止而導致虛擬機器效能出現問題，請根據該虛擬機器上執行的軟體製造商的建議以及該虛擬機器運行的實體伺服器的功能來選擇虛擬機器大小。
不要添加預留的核心；這可能不僅會導致虛擬機器本身出現效能問題，還會導致伺服器上的鄰居出現效能問題。
其他有用的 CPU 指標
跑 – 在測量期間，vCPU 處於 RUN 狀態的時間（毫秒），即它實際上正在執行有用的工作。
空閒 – 在測量期間 vCPU 處於不活動狀態的時間長度（毫秒）。 高空閒值不是問題，vCPU 只是「無事可做」。
等待 – 在測量期間 vCPU 處於等待狀態的時間長度（毫秒）。 由於 IDLE 包含在該計數器中，因此高 Wait 值也不表示有問題。 但是，如果當 Wait 為高時，Wait IDLE 為低，則表示 VM 正在等待 I/O 操作完成，而這反過來可能表明硬碟或 VM 的任何虛擬設備的效能存在問題。
最大限制 – 在測量期間，由於設定的資源限制，vCPU 處於就緒狀態的時間長度（毫秒）。 如果效能莫名其妙地低，那麼檢查該計數器的值和虛擬機器設定中的 CPU 限制會很有用。 虛擬機器可能確實存在您不知道的限制。 例如，當從設定了 CPU 限制的範本複製 VM 時，就會發生這種情況。
交換等待 – 在測量期間，vCPU 等待 VMkernel Swap 操作的時間。 如果這個計數器的值大於零，那麼VM一定有效能問題。 我們將在有關 RAM 計數器的文章中詳細討論 SWAP。
ESXTOP
如果 vCenter 中的效能計數器適合分析歷史數據，那麼問題的操作分析最好在 ESXTOP 中完成。 這裡，所有值都以現成的形式呈現（無需翻譯任何內容），最小測量週期為2秒。
使用“c”鍵呼叫 CPU 的 ESXTOP 螢幕，如下所示：
為了方便起見，您可以按 Shift-V 僅保留虛擬機器進程。
若要查看各個 VM 核心的指標，請按「e」並輸入感興趣的 VM 的 GID（下面螢幕截圖中的 30919）：
讓我簡要瀏覽一下預設顯示的列。 可以按“f”來新增其他列。
NWLD（世界數） – 群組中的進程數。 若要展開群組並查看每個流程的指標（例如，多核心虛擬機器中的每個核心），請按下「e」。 如果一組中有多個進程，則該組的指標值等於各個進程的指標總和。
％用過的 – 一個行程或一組行程使用了多少個伺服器 CPU 週期。
％跑步 – 在測量期間過程處於運作狀態的時間有多長，即做了有用的工作。 它與 %USED 的不同之處在於它不考慮超線程、頻率縮放和系統任務所花費的時間 (%SYS)。
%系統 – 系統任務所花費的時間，例如：中斷處理、I/O、網路操作等。如果 VM 具有大量 I/O，則該值可能會很高。
%OVRLP – 運行VM進程的實體核心在其他進程的任務上花了多少時間。
這些指標相互關聯如下：
%USED = %RUN + %SYS - %OVRLP。
通常，%USED 指標資訊更豐富。
％等待 – 在測量期間過程處於等待狀態的時間有多長。 啟用空閒。
％閒置的 – 在測量期間過程處於空閒狀態的時間有多長。
%SWPWT – 在測量期間，vCPU 等待 VMkernel Swap 操作的時間。
%VM等待 – 在測量期間，vCPU 處於等待事件（通常是 I/O）狀態的時間有多長。 vCenter 中沒有類似的計數器。 高值表示 VM 上的 I/O 有問題。
%WAIT = %VMWAIT + %IDLE + %SWPWT。
如果 VM 不使用 VMkernel Swap，則在分析效能問題時，建議查看 %VMWAIT，因為該指標不考慮 VM 不執行任何操作的時間 (%IDLE)。
%RDY – 在測量期間過程處於就緒狀態的時間有多長。
%CSTP – 在測量期間過程處於成本停止狀態的時間有多長。
%MLMTD – 在測量期間，由於設定的資源限制，vCPU 處於就緒狀態的時間有多長。
%WAIT + %RDY + %CSTP + %RUN = 100% – VM 核心始終處於這四種狀態之一。
虛擬機器管理程式上的 CPU
vCenter 還具有虛擬機器管理程式的 CPU 效能計數器，但它們沒什麼有趣的 - 它們只是伺服器上所有虛擬機器的計數器的總和。
查看伺服器上 CPU 狀態的最方便方法是在「摘要」標籤上：
對於伺服器以及虛擬機，有一個標準警報：
當伺服器CPU負載較高時，其上執行的虛擬機器開始出現效能問題。
在 ESXTOP 中，伺服器 CPU 負載資料顯示在螢幕頂部。 除了標準 CPU 負載（對於虛擬機器管理程式來說資訊量不大）之外，還有另外三個指標：
核心利用率(%) – 載入實體伺服器核心。 此計數器顯示在測量期間核心執行工作的時間。
PCPU 使用率(%) – 如果啟用超線程，則每個物理核心有兩個線程 (PCPU)。 此指標顯示每個執行緒完成工作所需的時間。
PCPU 使用率(%) – 與 PCPU UTIL(%) 相同，但考慮了頻率縮放（出於節能目的降低核心頻率，或由於 Turbo Boost 技術而提高核心頻率）和超線程。
PCPU_USED% = PCPU_UTIL% * 有效核心頻率/額定核心頻率。
在此螢幕截圖中，對於某些核心，由於睿頻加速，USED 值大於 100%，因為核心頻率高於標稱頻率。
關於如何考慮超線程的幾句話。 如果進程 100% 的時間在伺服器物理核心的兩個執行緒上執行，而核心以標稱頻率運行，則：
- 核心的 CORE UTIL 將為 100%，
- 兩個執行緒的 PCPU UTIL 將為 100%，
- 兩個執行緒使用的 PCPU 將為 50%。
如果在測量期間兩個執行緒均未 100% 工作，則在執行緒並行工作的那些期間，用於核心的 PCPU 將被分成兩半。
ESXTOP 還有一個螢幕，顯示伺服器 CPU 功耗參數。 在這裡您可以看到伺服器是否使用節能技術：C狀態和P狀態。 透過“p”鍵調用：
常見的 CPU 效能問題
最後，我將回顧虛擬機器 CPU 效能問題的典型原因，並提供解決這些問題的簡短提示：
核心主頻不夠。 如果無法將虛擬機器升級到更強大的內核，您可以嘗試更改電源設定以使 Turbo Boost 更有效率地工作。
VM 大小不正確（核心太多/太少）。 如果安裝的核心較少，VM 上的 CPU 負載將會很高。 如果有很多，請抓住一個高的共同停止。
伺服器上的 CPU 大量超額認購。 如果VM的Ready狀態較高，則減少CPU超額訂閱。
大型虛擬機器上的 NUMA 拓樸不正確。 VM (vNUMA) 看到的 NUMA 拓樸必須與伺服器 (pNUMA) 的 NUMA 拓樸相符。 例如，書中寫有此問題的診斷和可能的解決方案 。 如果您不想更深入，並且對虛擬機器上安裝的作業系統沒有許可限制，請在虛擬機器上建立許多虛擬套接字，一次一個核心。 你不會損失太多:)
這就是我對 CPU 的全部了解。 問問題。 在下一部分我將討論 RAM。
有用的鏈接
來源： www.habr.com