ESX/ESXi 仮想マシンのパフォーマンス問題のトラブルシューティング
search cancel

ESX/ESXi 仮想マシンのパフォーマンス問題のトラブルシューティング

book

Article ID: 323248

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms:

免責事項： これは英文の記事 「Troubleshooting ESX/ESXi virtual machine performance issues (2001003)」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

  • ゲスト仮想マシンで実行されているサービスの応答が遅い。
  • ゲスト仮想マシンで実行されているアプリケーションが断続的に応答する。
  • ゲスト仮想マシンの応答が遅いか、または応答しない。


Resolution

この記事では、ESXi/ESX でのパフォーマンス問題の隔離に関する情報について記載されています。 パフォーマンスの低下は、次のいくつかの異なる領域が原因で発生する可能性があります。 CPU の制約、メモリのオーバーコミット、ストレージ待ち時間、またはネットワーク待ち時間。 仮想マシンの 1 つ以上で応答時間が遅くなった場合は、これらの各領域について検討してボトルネックを見つけてください。

次の各手順には、指示および該当するドキュメントへのリンクが含まれています。

手順は、問題を隔離し、適切な解決方法を特定するために最適な順番で並べられています。 また、手順は、データの損失を最小限に抑えるために最適な順序で記載されています。

注： 各手順を完了したら、パフォーマンス問題がまだ存在するかどうか確認してください。 トラブルシューティングの手順はそれぞれ順番に実行し、手順を飛ばさないでください。

この記事には次の 4 つの主要なセクションがあります。

CPU の制約

パフォーマンスの低下が CPU の制約によるものかどうかを判別するには、次の手順を実行します。

  1. esxtop コマンドを使用して、ESXi/ESX サーバが過負荷状態かどうかを判別します。 esxtop の詳細については、該当する ESXi/ESX バージョンの『リソース管理ガイド』を参照してください。
     
    1. コマンド出力の最初の行の load average を調べます。

      負荷平均が 1.00 の場合は、ESXi/ESX サーバ マシンの物理 CPU がフルに使用されていることを意味し、負荷平均が 0.5 の場合は半分まで使用されていることを意味します。 負荷平均が 2.00 の場合は、システムが全体として過負荷状態になっていることを意味します。
       
    2. %READY フィールドで、仮想マシンの準備ができていても、物理 CPU で実行するようにスケジュールできなかった時間の割合を調べます。

      通常の動作状態では、この値が 5% 未満を保つようにする必要があります。 パフォーマンスが低下している仮想マシンでの準備時間の値が長くなっている場合は、CPU の制限があるかどうか確認してください。
       
      • 仮想マシンがそれ自体に設定された CPU 制限による制約を受けないことを確認します。
      • 仮想マシンがそのリソース プールによる制約を受けないことを確認します。

        詳細については、「Impact of virtual machine memory and CPU resource limits (1033115)」を参照してください。
         
    負荷平均が過度に高く、準備時間が CPU 制限の制約を受けない場合は、ホストの CPU 負荷を調整してください。 ホストの CPU 負荷を調整するには、次のいずれかを実行します。
     
    • ホストの物理 CPU の数を増やします。

      または
       
    • ホストに割り当てられている仮想 CPU の数を減らします。 ホストに割り当てられている仮想 CPU の数を減らすには、次のいずれかを実行します。
       
  2. ESX 3.5 を使用する場合は、IRQ 共有が問題になっているかどうかを判断してください。 詳細については、「ESX has performance issues due to IRQ sharing (1003710)」を参照してください。

メモリのオーバーコミット

パフォーマンスの低下の原因がメモリのオーバーコミットかどうかを判断するには、次の手順を実行します。

  1. esxtop コマンドを使用して、ESXi/ESX サーバのメモリがオーバーコミットされているかどうかを判断します。 esxtop の詳細については、該当する ESXi/ESX バージョンの『リソース管理ガイド』を参照してください。
     
    1. コマンド出力の最初の行の MEM overcommit avg を調べます。 この値は、使用可能なメモリに対する要求されたメモリの比率から 1 を引いた値です。

      例：
       
      • 仮想マシンで 4GB の RAM を必要とし、ホストに 4GB の RAM がある場合、比率は 1:1 です。 1 を減算する（1/1 から）と、MEM overcommit avg フィールドの読みは 0 になります。 この場合、オーバーコミットはなく、余分の RAM は必要ありません。
      • 仮想マシンで 6 GB の RAM を必要とし、ホストに 4GB の RAM がある場合、比率は 1.5:1 です。 1 を減算する（1.5/1 から）と、 MEM overcommit avg フィールドの読みは 0.5 になります。 RAM は 50% オーバーコミットされており、これは、使用可能な RAM に比べ RAM がもう 50% 必要であることを意味します。
         
    メモリがオーバーコミットされている場合は、ホストのメモリ負荷を調整します。 メモリ負荷を調整するには、次のいずれかを実行します。
     
    • ホストの物理 RAM の容量を増やします。

      または
       
    • 仮想マシンに割り当てられている RAM の容量を減らします。 割り当てられる RAM の容量を減らすには、次のいずれかを実行します。
       
      • ホストのすべての仮想マシンに割り当てられている RAM の合計容量を減らします。

        または
         
      • ホストの仮想マシンの合計数を減らします。
         
  2. 仮想マシンがバルーニングまたはスワップしているかどうかを判断します。

    バルーニングまたはスワップを検出するには、次の手順を実行します。
     
    1. esxtop を実行します。
    2. メモリの場合は m と入力します
    3. フィールドの場合は f と入力します。
    4. メモリ バルーニング統計 (MCTL) の場合は文字 J を選択します。
    5. MCTLSZ 値を確認します。

      MCTLSZ (MB) バルーン ドライバによって解放されたゲスト物理メモリの容量が表示されます。
       
    6. フィールドの場合は f と入力します
    7. メモリ スワップ統計の文字を選択します (SWAP STATS)。
    8. SWCUR 値を確認します。

      SWCUR (MB) には、現在のスワップ使用量が表示されます。
       
    この問題を解決するには、不適切に設定されているメモリ制限が原因でバルーニングまたはスワップが発生しないようにします。 メモリ制限が不適切に設定されている場合は、適切な設定にリセットします。 詳細については、次を参照してください。
     

ストレージ待ち時間

パフォーマンスの低下の原因がストレージの待ち時間かどうかを判断するには、次の手順を実行します。

  1. 問題がローカル ストレージに関係するかどうかを判断します。 仮想マシンを別のストレージの場所に移行します。
  2. LUN あたりの仮想マシンの数を減らします。
  3. Windows ゲストで次のようなログ エントリを探します。

    The device, \Device\ScsiPort0, did not respond within the timeout period.
     
  4. esxtop を使用して、高い値の DAVG 待ち時間を探します。 詳細については、「Using esxtop to identify storage performance issues (1008205)」を参照してください。
  5. iometer コマンドによって実現可能な最大 I/O スループットを判断します。 詳細については、「Testing virtual machine storage I/O performance for VMware ESXi and ESX (1006821)」を参照してください。
  6. VM の iometer の結果を、同じストレージに接続された物理マシンの場合の結果と比較します。
  7. SCSI 予約の競合がないかどうか確認します。 詳細については、「Analyzing SCSI Reservation conflicts on VMware Infrastructure 3.x and vSphere 4.x (1005009)」を参照してください。
  8. iSCSI ストレージおよびジャンボ フレームを使用する場合は、すべてが適切に構成されていることを確認してください。 詳細については、次を参照してください。
     
  9. iSCSI ソフトウェア イニシエータで iSCSI ストレージとマルチパスを使用する場合は、すべてが適切に構成されていることを確認してください。 詳細については、『iSCSI SAN 構成ガイド』の次のセクションを参照してください。
     
ストレージ関連の問題を特定する場合
  1. ハードウェア アレイおよび HBA カードが ESX/ESXi で認証されていることを確認します。 詳細については、「VMware Hardware Compatibility List」を参照してください。
  2. 物理サーバの BIOS が最新の状態になっていることを確認します。 詳細については、「Checking your firmware and BIOS levels to ensure compatibility with ESX/ESXi (1037257)」を参照してください。
  3. HBA のファームウェアが最新の状態になっていることを確認します。 詳細については、「Slow performance caused by out of date firmware on a RAID controller or HBA (1006696)」を参照してください。
  4. ESX が SATP ストレージ アレイ タイプと PSP パス選択の正しいモードとパス ポリシーを認識できることを確認します。 詳細については、「Verifying correct storage settings on ESX 4.x, ESXi 4.x and ESXi 5.0 (1020100)」を参照してください。

ネットワーク待ち時間

ネットワーク パフォーマンスは、CPU パフォーマンスの影響を大きく受ける可能性があります。 ネットワークの待ち時間を調査する前に、CPU パフォーマンスの問題を排除してください。

パフォーマンスの低下の原因がネットワーク待ち時間かどうかを判断するには、次の手順を実行します。

  1. Iperf ツールにより、仮想マシンからの最大バンド幅をテストします。 このツールは、https://code.google.com/p/iperf/ で入手可能です。

    注： VMware は、特定のサードパーティ製ユーティリティを保証または推奨するものではありません。
     
    1. Iperf の使用中に、TCP ウィンドウ サイズを 64 K に変更します。 パフォーマンスはこの値にも依存します。 TCP ウィンドウのサイズを変更するには、次の手順を実行します。
       
      1. サーバ サイドで、次のコマンドを入力します。

        iperf -s
         
      2. クライアント サイドで、次のコマンドを入力します。

        iperf.exe -c sqlsed -P 1 -i 1 -p 5001 -w 64K -f m -t 10 900M

詳細については、http://openmaniak.com/iperf.php を参照してください。
 

  1. ESXi/ESX ホストの外部のマシンで lperf を実行します。 物理環境に応じて、結果を自分で予測する結果と比較します。
  2. 同じ物理スイッチにある VLAN 上の ESXi/ESX ホスト外部の別のマシンで lperf を実行します。 パフォーマンスが良好で、地理的に別の場所のマシンでのみ問題を再現できる場合、その問題はネットワーク環境に関連しています。
  3. 同じ ESX サーバ/portgroup/vswitch 上の 2 つの VM 間で lperf を実行します。 結果が良好な場合は、CPU、メモリ、またはストレージ問題を除外できます。
ネットワーク上のボトルネックを特定する場合
  1. 「Troubleshooting network performance issues (1004087)」で説明されている手順を実行します。
  2. iSCSI ストレージおよびジャンボ フレームを使用する場合は、すべてが適切に構成されていることを確認してください。 詳細については、次を参照してください。
     
  3. Network I/O Control を使用する場合は、トラフィックの共有および制限が正しく構成されていることを確認します。 詳細については、「Network I/O Resource Management in vSphere 4.1 with vDS (1022585)」を参照してください。
  4. トラフィック シェーピングが正しく構成されていることを確認します。 詳細については、『ESXi/ESX 構成ガイド』の「Traffic Shaping Policy」を参照してください。


Additional Information

記載されているトピックの詳細については、次のリソースを参照してください。

CPU

Memory

ストレージ

Troubleshooting ESX/ESXi virtual machine performance issues

Powered by Wolken Software