如何利用 CPU Ready、記憶體氣球及交換指標診斷虛擬機效能？

技術原理與管理重點

CPU Ready 反映虛擬 CPU 等待 ESXi 排程到實體 CPU 的時間。單一尖峰未必代表持續瓶頸；應按取樣區間、vCPU 數量、同主機 VM 數目及應用程式延遲觀察，並與 CPU 使用量、共用值、限制及主機負載交叉核對。

ESXi 可透過 VMware Tools 的記憶體氣球機制向客戶機要求回收部分記憶體，以應對主機記憶體壓力。氣球出現不等同於立即故障，但持續或伴隨交換、壓縮及應用程式延遲時，應調查資源配置和工作負載。

主機可能使用記憶體壓縮或交換處理壓力，對延遲敏感的工作負載尤其需要關注。診斷時要把 VM、ESXi 主機、叢集資源集區、保留值、限制、NUMA、快照及儲存延遲放在同一時間線分析。

實際功能、介面名稱與支援條件會因 vSphere 或 vSAN 版本、授權、伺服器平台、儲存裝置及更新狀態而異。正式變更前，應核對現行 Broadcom VMware 文件、硬件相容性資料與企業變更政策，並先在非生產環境驗證。

記錄使用者感受到的延遲時間、VM 內 CPU/記憶體/磁碟指標、vCenter 效能圖表、ESXi 主機 CPU 及記憶體壓力，並標記備份、掃描、批次工作、vMotion 或維護事件。只有把相同時段的資料對齊，才可避免把相關性當成根因。

若多部 VM 同時出現 CPU Ready，先查看主機是否過度配置、VM 是否配置過多 vCPU、資源集區是否有共享值或限制，以及 DRS 放置是否均衡。記憶體問題則檢查保留值、氣球、壓縮、交換、客戶機 Tools 狀態及主機剩餘容量，先處理持續性資源壓力。

可以在受控窗口調整 vCPU、資源集區、保留值、限制、VM 放置或增加主機容量，但每次只改變可追蹤的因素。完成後以相同工作負載和時間窗口比較 CPU Ready、氣球、交換、儲存延遲及應用程式交易時間，並記錄回復方案。

本文技術內容按 TSV 規劃的認證範圍及技術範圍，交叉參考以下原廠或標準機構資料：

不確定如何應用於實際環境？我們的工程師可按現場情況提供建議，免費解答及報價。

WhatsApp 即時查詢

CPU Ready 高是否一定代表 CPU 不夠？

不一定。它可能與主機爭用、VM 配置過多 vCPU、資源集區政策、限制或工作負載同時出現有關。應按相同時間段查看主機、叢集、VM 及應用程式指標後再決定處理方式。

Ballooning 是否代表 VMware Tools 壞了？

不是。氣球機制需要客戶機內的 VMware Tools 配合，但出現氣球通常首先表示 ESXi 正在處理記憶體壓力。若數值異常或無法回收，才再檢查 Tools 狀態、客戶機及主機配置。

Ballooning 和 Swapping 有什麼分別？

Ballooning 是透過客戶機驅動協助回收記憶體；Swapping 是把部分記憶體內容移到交換位置。兩者都要結合主機壓力、延遲及應用程式反應判斷，不能只看單一指標。

應否把每部 VM 的 vCPU 都加大？

不應直接加大。過多 vCPU 可能增加排程等待，未必改善應用程式效能。應先確認應用程式需求、實體 CPU、NUMA、主機爭用及歷史指標，再以小幅、可回復的變更驗證。

效能排錯要看哪一個時間範圍？

先以使用者報告的故障窗口作短時間對照，再查看較長的日、週趨勢，分辨瞬時尖峰和持續資源不足。不同圖表的取樣粒度及單位亦要先確認。

主機資源足夠但 VM 仍然慢，下一步是什麼？

把儲存延遲、網絡、客戶機檔案系統、應用程式鎖定、備份或掃描工作，以及 VM 快照和 Tools 狀態一併納入時間線。CPU Ready 或氣球不是所有效能問題的唯一原因。

HKEZIT 可協助企業評估伺服器、網絡、儲存、備份及系統整合需要，按現場環境制定方案。

若閣下正計劃相關工程或需要選購設備，歡迎瀏覽網絡工程服務了解方案詳情，或透過網上快速報價與我們的工程師聯絡。