vmstat コマンド

最初に使用するツールは vmstat コマンドで、 各種システム・リソースと関連するパフォーマンス上の問題に関する情報を迅速に提供してくれます。

vmstat コマンドは、実行キューおよび待機キュー、メモリー、 ページング、ディスク、割り込み、システム・コール、コンテキスト切り替え、 および CPU アクティビティーにおけるカーネル・スレッドに関する統計情報を報告します。 報告される CPU アクティビティーは、ユーザー・モード、システム・モード、 アイドル時間、およびディスク入出力の待ちの分類パーセンテージです。
注: 間隔を指定せずに vmstat コマンドを使用すると、単一のレポートが生成されます。 この単一のレポートは、システムが始動した時点からの平均レポートです。 Interval パラメーターを指定した Count パラメーターのみを指定できます。 Interval パラメーターを Count パラメーターと組み合わせないで指定する場合、レポートは継続的に生成されます。
CPU モニターとして、vmstat コマンドは、1 レポートごとに 1 行の出力がスクロール時にスキャンしやすく、システムに多数のディスクが接続されている場合もオーバーヘッドが大きくならないので、iostat コマンドより優れています。 次の例を見れば、プログラムが暴走しているか、過度の CPU 集中のために、 マルチユーザー環境では実行できない状態を確認することができます。
# vmstat 2
kthr     memory             page              faults        cpu
----- ----------- ------------------------ ------------ -----------
 r  b   avm   fre  re  pi  po  fr   sr  cy  in   sy  cs us sy id wa
 1  0 22478  1677   0   0   0   0    0   0 188 1380 157 57 32  0 10
 1  0 22506  1609   0   0   0   0    0   0 214 1476 186 48 37  0 16
 0  0 22498  1582   0   0   0   0    0   0 248 1470 226 55 36  0  9

 2  0 22534  1465   0   0   0   0    0   0 238  903 239 77 23  0  0
 2  0 22534  1445   0   0   0   0    0   0 209 1142 205 72 28  0  0
 2  0 22534  1426   0   0   0   0    0   0 189 1220 212 74 26  0  0
 3  0 22534  1410   0   0   0   0    0   0 255 1704 268 70 30  0  0
 2  1 22557  1365   0   0   0   0    0   0 383  977 216 72 28  0  0

 2  0 22541  1356   0   0   0   0    0   0 237 1418 209 63 33  0  4
 1  0 22524  1350   0   0   0   0    0   0 241 1348 179 52 32  0 16
 1  0 22546  1293   0   0   0   0    0   0 217 1473 180 51 35  0 14

この出力は、使用中のマルチユーザー・システムでタイト・ループに入っているプログラムを実行した場合の影響を示しています。 最初の 3 つのレポート (要約は削除されている) は、システムが 50% から 55% のユーザー、30% から 35% のシステム、 および 10% から 15% の入出力待ちで均衡していることを示しています。 プログラムのループが始まると、使用可能な CPU サイクルがすべてそれに消費されます。 ループしているプログラムでは入出力が行われないので、 以前は入出力待ちのために使用されていなかったサイクルをすべて吸収してしまう可能性があります。 さらに悪いことに、このプログラムは、有効なプロセスが CPU を解放したときに、 いつでもそれを引き継ぐ用意ができているプロセスということになります。 ループしているプログラムは他のすべてのフォアグラウンド・プロセスと同じ優先順位を持っているので、 他のプロセスがディスパッチ可能になった場合にも CPU を手放す必要はありません。 プログラムが 10 秒程 (5 つのレポート) 実行した後、vmstat コマンドによって報告されるアクティビティーはより正常なパターンに戻ります。

最適の使用方法では、CPU が 100% の時間働きます。 これは、CPU を共有する必要のない単一ユーザー・システムの場合は成立します。 通常、us+sy時間が 90% 未満の場合、単一ユーザー・システムは CPU 制約と見なされません。 ただし、us+syマルチユーザー・システムでの時間が 80% を超えると、プロセスは実行キューで待機する時間を費やす可能性があります。 その結果、応答時間とスループットが低下します。

CPU がボトルネックであるかどうかを確認するには、以下の 4 つを考慮してください。cpu列と 2 つのkthr(カーネル・スレッド) vmstat レポートの列 また、以下を確認する価値がある場合もあります。faults桁:

  • cpu

    間隔中の CPU 時間使用率の分類パーセンテージ。 このcpu列は以下のとおりです。

    • us

      このus列には、ユーザー・モードで費やされた CPU 時間のパーセントが表示されます。 UNIX プロセスは、ユーザーモードでもシステム (カーネル) モードでも実行できます。 ユーザー・モードでは、プロセスはそのアプリケーション・コード内部で実行され、 計算の実行、メモリーの管理、あるいは変数の設定にカーネル・リソースを必要としません。

    • sy

      このsy列には、CPU がシステム・モードでプロセスを実行していた時間の割合が示されます。 これには、カーネル・プロセス (kprocs) およびカーネル・リソースへのアクセスが必要なその他のプロセスによって消費された CPU リソースが含まれます。 カーネル・リソースを必要とするプロセスは、システム・コールの実行が必要なので、 システム・モードへ切り替えてそのリソースを使用可能にします。 例えば、メモリーのマップ・ファイルを使用している場合を除いて、 ファイルの読み書きにはそのファイルのオープン、特定ロケーションへのシーク、 およびデータの読み書きのためのカーネル・リソースが必要です。

    • id

      このid列には、CPU がローカル・ディスク入出力を保留せずにアイドルまたは待機している時間のパーセンテージが示されます。 実行に使用できるスレッドがない場合 (実行キューが空)、 システムは wait というスレッドをディスパッチします。このスレッドは、idle kproc としても知られています。 SMP システムでは、各プロセッサーごとに 1 つの wait スレッドをディスパッチできます。 ps コマンド ( -k または -g 0 オプションを指定) によって生成されるレポートは、これを次のように識別します。kprocまたはwaitps レポートにこのスレッドの高い集約時間が示されている場合、CPU 上で実行する準備ができている、または実行を待機しているスレッドが他に存在しない、かなりの期間があったことを意味します。 したがって、システムはほとんどアイドル および新規タスク待ち 状態でした。

    • wa

      このwa列には、保留中のローカル・ディスク入出力と NFSマウント・ディスクがある状態で CPU が アイドル であった時間のパーセンテージが示されます。 wait の実行中にディスクに対する未解決の入出力がある場合、その時間は入出力待ちに分類されます。 プロセスが非同期通信 I/O を使用している場合を除き、ディスクに対する入出力要求では、要求が完了するまで呼び出しプロセスはブロック (またはスリープ) します。 プロセスの入出力要求が完了すると、呼び出しプロセスは実行キューに置かれます。 入出力が早く完了していれば、CPU 時間を多く使用できた可能性があります。

      Awa25% を超える値は、ディスク・サブシステムが適切に平衡化されていない可能性があること、またはディスク集中型ワークロードの結果である可能性があります。

      以下に対して行われた変更については、wa入出力待機時間レポートを参照してください。

  • kthr

    サンプリング間隔中における、さまざまなキュー内での 1 秒当たり平均カーネル・スレッド数。 このkthr列は以下のとおりです。

    • r

      実行可能なカーネル・スレッドの平均数。この中には、実行中のスレッドと、CPU 待ちのスレッドが含まれます。 この数が、CPU の数より多いときは、少なくとも 1 つのスレッドが CPU を待っています。CPU 待ちのスレッド数が多いほど、パフォーマンスへの影響が大きくなる傾向にあります。

    • b

      VMM 待機キュー内にある 1 秒当たりの平均カーネル・スレッド数。 この中には、ファイルシステムの入出力を待っているスレッド、またはメモリー・ロード制御のために中断されていたスレッドが含まれます。

      メモリー・ロード制御のためにプロセスが中断された場合、ブロックされた列 (b) vmstat レポートには、実行キューではなくスレッド数の増加が示されます。

    • p

      vmstat -I の場合、ロー・デバイスへの入出力を待っている 1 秒当たりスレッド数。 ファイルシステムへの入出力を待っているスレッドは、ここに含まれません。

  • フォールト

    トラップや割り込み率などの、プロセス制御に関する情報。 このfaults列は以下のとおりです。

    • in (存在する)

      その間隔で監視されたデバイス割り込みの 1 秒当たりの数。 追加情報については、 vmstat コマンドによるディスク・パフォーマンスの評価を参照してください。

    • sy

      その間隔中に監視されたシステム・コールの 1 秒当たりの数。 リソースは、明確に定義されたシステム・コールによって、ユーザー・プロセスが使用できます。 このようなコールは、カーネルに対して呼び出しプロセスのための操作を実行し、 カーネルとプロセスの間でデータを交換するように指示します。 ワークロードとアプリケーションの種類はさまざまで、 さらに多様なコールが異なる機能を実行するので、1 秒当たりのシステム・コール数がどの程度になると多すぎるのかを定義することは不可能です。 しかし一般的にはsyユニプロセッサー上で 1 秒当たり 10000 回を超える呼び出しが発生すると、さらに調査が呼び出されます (SMP システムでは、1 プロセッサー当たり 1 秒当たり 10000 回の呼び出しの数)。 この理由の 1 つは、 例えば select() サブルーチンのような「ポーリング」サブルーチンです。 この列については、通常のカウントを提供するベースライン測定を使用することをお勧めします。sy移ります。

    • cs

      その間隔で監視されたコンテキスト切り替えの 1 秒当たりの数。 物理的 CPU リソースは、 それぞれが 10 ミリ秒の論理タイム・スライスに分割されます。 スレッドは、実行のためにスケジュールされているとすると、 タイム・スライスが期限切れになるまで、他のスレッドに優先使用されるまで、 または自発的に CPU の制御を手放すまで、実行を続けます。 他のスレッドが CPU の制御を与えられると、 直前のスレッドのコンテキストまたは作業環境を保管して、現行スレッドのコンテキストをロードする必要があります。 オペレーティング・システムには非常に有効なコンテキスト切り替えプロシージャーがあるので、 切り替えのたびにリソースを多く消費することはありません。 コンテキスト・スイッチの大幅な増加 (以下の場合など)csディスク入出力およびネットワーク・パケット率よりもはるかに高いため、さらに調査を行う必要があります。