Posted inVMware

VMware仮想マシンのパフォーマンス最適化：本番環境から学んだ実践チェックリスト

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

8台のESXiホストで構成されるVMwareクラスタを6ヶ月間管理してきた経験から、オンラインドキュメントの多くが見落としているチェックリストをまとめました。VMが遅い、CPU使用率が異常に高い、ディスクI/Oにラグがある？この記事では、理論的な説明を省いて、ステップごとのデバッグと修正方法を直接解説します。

クイックスタート：5分でできる3つのチェック

設定の詳細に踏み込む前に、VMにパフォーマンスの問題が発生したときに即座に確認すべき3つの項目があります。

1. VMware Toolsのインストール（未インストールの場合）

前任チームからインフラを引き継ぐたびに遭遇する問題です。VMware Toolsが入っていないVMは、オイルなしで走る車のようなもの——動きはするが、劣化が速くパフォーマンスも明らかに落ちます。Toolsはメモリ用の準仮想化ドライバ、バルーンドライバ、そして正確な時刻同期を提供します。

Ubuntu/Debianの場合：

sudo apt update && sudo apt install open-vm-tools open-vm-tools-desktop -y
sudo systemctl enable open-vm-tools && sudo systemctl start open-vm-tools

CentOS/RHEL/Rocky Linuxの場合：

sudo yum install open-vm-tools -y
sudo systemctl enable vmtoolsd && sudo systemctl start vmtoolsd

# 実行確認
vmware-toolbox-cmd -v

2. バルーンドライバーの膨張状態を確認する

VMwareはホストがメモリ不足になると、バルーンドライバーを使ってVMからRAMを回収します。バルーンが膨張している場合、VMはRAMを知らないうちに奪われており、ゲストOS内側からは気づきにくいパフォーマンス低下の第一の原因となります。

vSphere Clientで確認：VM → Monitor → Memory → Balloon。Balloonの値が0 MBを超えている場合、ホストがRAM不足でVMからメモリを回収していることを意味します。

3. PVSCSIとVMXNET3への切り替え

VM Settingsで以下を変更します：

  • ハードディスクアダプター：LSI Logic SCSI → VMware Paravirtual (PVSCSI)
  • ネットワークアダプター：E1000 → VMXNET3

具体的な結果として、あるデータベースVMのCPU使用率がディスクアダプターの変更だけで15%から8%に低下しました。PVSCSIとVMXNET3はパラバーチャルドライバーで、VMwareが物理ハードウェアをエミュレートせずに直接I/Oを処理するため、LSIやE1000と比べてオーバーヘッドが大幅に削減されます。

詳細解説：CPUとRAM

vCPUを増やすとVMが遅くなる場合がある

直感に反するように聞こえますが、チームに何度も説明してきたことです。VMwareはコスケジューリングの仕組みを使っており、複数のvCPUを持つVMを実行するには、ハイパーバイザーが必要な数の物理コアが同時に空いているのを待つ必要があります。2スレッドしか使わないアプリケーションに8 vCPUを割り当てると、VMwareは8コアが同時に空くのを待ち続け、CPUスケジューリングの遅延が急増します。

# ESXiホストにSSHで接続してesxtopを実行
esxtop

# 'c'を押してCPUビューに切り替え
# %READYの列：
#   < 5%  = 良好
#   5-10% = 許容範囲、要モニタリング
#   > 10% = 問題あり、vCPUを減らすかVMをマイグレーション

# バッチエクスポートで分析する場合：
esxtop -b -d 5 -n 12 > cpu_report.csv

8ホストクラスタに適用している構成：

  • Web/Appサーバー：2〜4 vCPU
  • データベースサーバー：4〜8 vCPU、ただしCPU Readyを常時監視すること
  • ビルドサーバー/CI：より多くてもOK——バッチワークロードのため低レイテンシ不要

RAM——VMをスワップさせるとパフォーマンスは完全に崩壊する

インフラレビューのたびにチームに繰り返すルールがあります：VMwareのスワップファイルは物理RAMより数百倍遅い。ホストがRAM不足になると、VMwareはVMのページをディスクにスワップし、パフォーマンスは即座に崩壊します。これは設定でどうにかなるものではありません。

# VMがスワップ中かどうか確認（Linuxゲスト内から実行）
vmstat 1 5
# 'si'（スワップイン）と'so'（スワップアウト）の列が0より大きい場合は要注意

# またはサッと概要を確認
free -h
cat /proc/meminfo | grep -E 'SwapTotal|SwapFree|SwapCached'

ホストがRAM不足の場合は、次の順序で対処します：重要度の低いVMのRAM Reservationを下げる → 空きメモリのあるホストへVMをvMotionする → 物理RAMを増設する。この順序を守り、いきなり3番目に飛ばないようにしましょう。

応用編：ディスクI/Oとスナップショット

Noisy neighbor——ディスク低速化の真犯人

本番環境で最も多く遭遇したボトルネックは、CPUでもRAMでもなく、同じデータストア上の複数VMによるディスクI/O競合でした。深夜2時にバックアップやデータベースのインデックス再構築を行っているVMが、同一LUN上の他のVM十数台を巻き込んで遅延させる——ユーザーは朝方にWebが遅いと感じるものの、原因が誰にもわからない、という状況です。

# ESXiでのディスクレイテンシ確認（esxtop使用）
esxtop
# 'd'を押してディスク/ストレージビューに切り替え

# DAVG列（デバイス平均レイテンシ - ms）：
#   < 5ms  = 良好
#   5-20ms = 許容範囲
#   > 20ms = 深刻な問題あり、要調査

# KAVG列：カーネルレイテンシ——高い場合はハイパーバイザースケジューリングに問題あり
# GAVG列 = DAVG + KAVG：VMから見た合計レイテンシ

データベースやI/O負荷の高いVMには、必ず以下の3つを適用します：

  • 専用データストアに配置し、他のVMと共有しない
  • Thick Provision Eager ZeroedをThin Provisionの代わりに使用——初回書き込み時のゼロフィルオーバーヘッドを回避
  • データストアレベルでStorage I/O Control (SIOC)を有効化し、VMwareがVM間のI/Oを自動的に調整できるようにする

長いスナップショットチェーン——最もじわじわとパフォーマンスを蝕むもの

スナップショットチェーンが15〜20個あるシステムを引き継いだことが何度もあります。VMwareは書き込みのたびに複数のデルタファイル層を読み込む必要があるため、ディスクI/Oが極端に遅くなります。最悪のケースとして経験したのは、8ヶ月前から蓄積された18個のスナップショットチェーンによってDAVGが80msまで跳ね上がったケースです。

# PowerCLIでスナップショットを確認
Connect-VIServer -Server vcenter.company.local
Get-VM "VMName" | Get-Snapshot | Select Name, Created, SizeGB | Format-Table

# クラスタ内のスナップショットを持つ全VMを表示
Get-VM | Get-Snapshot | Select VM, Name, Created, SizeGB | Sort-Object SizeGB -Descending

スナップショットはパッチ適用やアップグレードの直前にのみ作成し、問題がないことを確認したらすぐに削除しましょう。スナップショットを長期バックアップとして使うのは用途が違います——それはVeeamやNakivoの仕事です。

実践Tips：モニタリングとCPU/RAM Reservation

Reservationを使うべき場合

VMwareではReservationを設定することで、VMに最低限のリソースを保証できます。設定するのは本番データベースVMとリアルタイムワークロードのみに限定しています——リソースが奪われると即座にユーザーに影響が出るものだけです。

Reservationを闇雲に設定してはいけません。リソースがロックされることで、DRS（Distributed Resource Scheduler）がホスト間の負荷分散を行いにくくなり、クラスタ全体のキャパシティが目に見えて低下します。

ワークロード別の推奨構成

6ヶ月の運用を経て、VMを3つのグループに分類しています：

  • Web/Appサーバー：VMXNET3 + PVSCSI + Thin Provision + 2〜4 vCPU、Reservation不要
  • データベースサーバー：PVSCSI + Thick Eager Zeroed + RAM Reservation + バルーンとスワップを常時監視
  • ビルドサーバー/CI：vCPU多めOK、Thin Provision OK、Reservation不要——高レイテンシ許容可

これらをすべて8台のESXiホストクラスタに適用した結果：CPU ready timeの平均が8%から2%以下に低下し、ディスクレイテンシが5ms以下で安定しました。特別な魔法ではありません——適切なドライバーの選択、スナップショットを短命に保つこと、そして正しい指標を見ること、それだけです。VMwareに関して具体的な問題でお困りの場合は、コメントに残してください——実際に経験したことをもとに回答します。

Share:
Tags: