5分で即対応：esxtopへのアクセスと操作方法
vCenterの応答が遅かったり、VMが「フリーズ」したりしているとき、Webインターフェースのグラフが読み込まれるのをただ待っていても、焦りが募るだけです。最も素早い対処法は、ESXiホストに直接SSHで接続し、次のコマンドを入力することです：
esxtopデフォルト画面にはCPUの統計情報が表示されます。他のリソースを確認するには、以下のキーショートカットを使用してください：
- c：CPUパフォーマンスを表示。
- m：RAM（メモリ）の詳細を確認。
- u：ディスクデバイスの統計を表示（ディスクレイテンシの確認に使用）。
- n：ネットワークトラフィックを監視。
- f：不要なデータ列の追加または非表示。
- V：仮想マシン（VM）の行のみを表示し、システムのバックグラウンドプロセスを除外。
ヒント：列のカスタマイズが完了したら、Wキーを押して設定を.esxtop4rcファイルに保存しましょう。次回起動時に、設定がすぐに反映されます。
CPU分析：%USEDが高くても必ずしも問題ではない理由
多くの管理者は%USEDの値が上昇すると心配しがちです。しかし仮想化の世界では、%RDY（Ready Time）こそが特に注目すべき指標です。
%RDY指標：待機時間の尺度
この値は、VMが処理の準備が完了しているにもかかわらず、ESXiホストからの物理CPU割り当てを待ってキューに入っている時間を示します。
- 5%未満：システムは非常に良好な状態で稼働しています。
- 5%〜10%：ボトルネックが発生し始めており、ユーザーはアプリケーションのわずかな遅延を感じるでしょう。
- 10%超：警告レベル。これは通常、1つのVMに過剰なvCPUを割り当てた（オーバープロビジョニング）結果です。
実際に私が経験したケースでは、32個のvCPUが割り当てられたWebサーバーが極めて低速で動作していました。esxtopで確認したところ、%RDYが20%に達していました。原因は、CPUスケジューラーがVMを実行するために32個の物理コアが同時に空くのを待つ必要があったためです。vCPUを4つに減らしたところ、即座にスムーズに動作するようになりました。覚えておいてください：vCPUが少ない方が、パフォーマンスが高くなることがあります。
%CSTP（Co-stop）指標
%CSTPが3%を超える場合、同一VM内の複数のvCPUが同期を失っています。これは通常、リソースが限られたホストに多数のマルチvCPU仮想マシンを詰め込みすぎた場合に発生します。
RAM問題の解明：ハードウェアのアップグレードが必要なのはいつか？
mキーを押してメモリタブに切り替えます。画面上部のMEM Overcommit avgの行を確認してください。この値が0より大きい場合、ホストが物理RAMの不足に苦しんでいることを意味します。
以下の3つの「危険な」指標を注意深く確認してください：
- MCTLSZ（MB）：Balloonドライバーによって回収されたRAMの量。この値が0より大きい場合、ホストはあるVMから別のVMを救うために「RAM借用」を行っています。
- SWCUR（MB）：現在ディスク（スワップ）に退避されているRAMの量。ディスクの速度はRAMより数百倍遅いため、この値が0より大きければ、VMは確実にフリーズやラグが発生します。
- ZIP/s（MB/s）：RAMの圧縮速度。ESXiはスワップを使用する前にデータを圧縮してスペースを節約します。この値が継続的に変動している場合、新しいRAMモジュールを追加する時期が来ています。
ストレージとネットワーク：I/Oボトルネックの原因を追跡する
ディスクレイテンシの測定
uキーを押してディスクデバイスを確認します。ここでデータベースクエリが遅い原因を特定できます。以下の3つの列に注目してください：
- DAVG/cmd：ハードウェア側（ストレージ/SAN）のレイテンシ。この値が20msを超える場合、ディスク、光ファイバーケーブル、またはSANスイッチの設定を確認してください。
- KAVG/cmd：ESXiカーネルによるレイテンシ。通常この値はほぼ0であるべきです。高い場合（1ms超）、RAID/HBAカードのドライバーまたはファームウェアに問題がある可能性があります。
- GAVG/cmd：VMが実際に経験する総レイテンシ（DAVG + KAVG）。
経験上、SSD/NVMeドライブを使用しているにもかかわらずGAVGが10msを超える場合、システムにはI/O設定に関する深刻な問題があることは間違いありません。
ネットワークのボトルネックを確認する
nキーを押してネットワークを表示します。MB/sの帯域幅を見る代わりに、%DRPRXと%DRPTX（ドロップされたパケット）の列に注目してください。これらの値が0以外の数値を示している場合、パケットが転送中に失われています。原因として、物理スイッチの過負荷や、VM内のVMXNET3ドライバーが最新バージョンに更新されていないことが考えられます。
上級編：バッチモードでesxtopを実行する
システムエラーの多くは、深夜のほんの一瞬に発生します。こうした瞬間を捉えるために、バッチモードを使用してデータをCSVファイルに記録しましょう：
esxtop -b -d 5 -n 200 > log_hieu_nang.csv上記のコマンドは、5秒ごとに統計情報を記録し、200回繰り返します。その後、ファイルをローカルマシンにダウンロードし、ExcelまたはVisualEsxtopで開いてグラフを作成し、傾向を分析できます。
システム管理者のための実践的なアドバイス
- vCenterを過信しない：vCenter上のデータには一定の遅延が生じます。
esxtopは完全な精度でリアルタイムデータを提供します。 - レイテンシのゴールデンルール：一般的なアプリケーションではGAVGを常に15ms未満に、データベース管理システム（SQL、Oracle）では5ms未満に保つようにしてください。
- 更新間隔のカスタマイズ：sキーを押して2を入力すると、画面の更新頻度が上がります（デフォルトは5秒）。
esxtopを使いこなすことで、システム低速の原因を推測する必要がなくなります。ハードウェア障害かソフトウェア設定の問題かを明確に切り分け、アップグレードや最適化について最も正確な意思決定を下すことができます。
