物理環境に比べて仮想マシンの動作環境は非常に複雑な構造を持っているため、パフォーマンスボトルネックが発生した際の原因特定は容易ではありません。そうした中での重要な手掛かりを示してくれるのがesxtop ユーティリティです。パフォーマンス調査に役立つ代表的なesxtopコマンドを紹介するとともに、発生した問題の原因切り分けおよび原因調査を行う際の基本的な取り組み方を説明しました。
esxtopを使ってシステム統計情報を一括取得
「期待した性能がでない」「仮想マシンが時々無反応になる」といった仮想環境のパフォーマンス問題が発生した場合、原因を調査するためにはデータが必要です。そこで利用していただきたいのが「esxtopユーティリティ」です。このツールをバッチモードで実行することで、システムの統計情報を一括取得することができます。なお、データの閲覧には「VisualEsxtop」のほか「Windows Performance Monitor」などもご利用いただけます。
基本的な手順としては、まずesxtopのコマンド[C]をタイプし、CPUが正常に動作しているか使用状況を確認します。特に重要なのが、「％RUN（CPUリソースの消費時間）」「％WAIT（待ち時間）」「％RDY（実行可能状態でスケジュール待ち時間）」「％CSTP（Co-Scheduling待ち）」の4つの項目です。
例えば、％RUNが高ければ「ゲストOS内の処理がbusyになっている」、％WAITが長くなおかつアイドル値が低ければ「イベント（I/O）待ち」、％RDYが高ければ「CPUのリソース不足」、％CSTPが高ければ「CPUのリソース不足または仮想CPU数が多すぎる」といったことを推測できます。
さらに、Sched-Statsコマンドを実行し、CPUスケジューラの統計情報、Run State詳細統計情報、Wait State詳細統計情報など、より詳細なCPU統計情報を取得します。
原因特定のための基本方針
これらの統計情報をもとにCPUがどこで時間を消費しているのかを確認し、可能性の高いところから原因を特定していきます。
メモリ不足が疑われる場合には、esxtopのコマンド[m]をタイプしてメモリ統計情報を確認します。まずシステム全体として「MEM overcommit」の値が0より大きい場合、メモリオーバーコミットメントが発生している可能性があります。そのほかSWAPによる影響が疑われる場合には、CPU統計情報の％SWPWTの値もあわせて確認してください。
さらに、問題のある仮想マシン単位のメモリ統計情報も確認します。ここでは特に「MEMSZ（物理マシンのメモリサイズ）」「GRANT（物理メモリ消費量）」「SWCUR（現在のスワップ済みサイズ）」「SWR/s（スワップの読み込み量）」「SWW/s（スワップの書き込み量）」「OVHD（オーバーヘッドメモリ）」などがポイントとなります。
ストレージI/Oの遅延が疑われる場合には、esxtopのコマンド[d][u][t]をタイプし、ストレージ統計情報を確認することに加え、vmkernel.logなどのログも確認します。ここでの重要ポイントは「CMDS/s（1秒あたりのコマンド数）」「DAVG/cmd（1コマンドあたりデバイスで消費した時間）」「KAVG/dmd（1コマンドあたりVMKernelで消費した時間）」「GAVG/cmd（1コマンドあたりゲストからみたラウンドトリップタイム）」などです。
そのほか問題の発生条件、再現性の有無、再現手順などについてもしっかり確認し、原因を切り分けていく必要があります。
2015年11月10日(火)-11日(水)に開催された vForum 2015 TOKYO のセッションをベースに制作されたものです。
本記事の詳細情報については、vForum 2015 当日のセッション資料をご覧ください。セッション資料はこちらからダウンロードいただくことができます。