【Linuxの基礎知識】vmstatとiostatでボトルネックを見抜く

Linuxサーバーの動作が遅いと感じたとき、あなたはまず何を確認しますか？

プロセス一覧を眺めたり、topコマンドでCPU使用率を見たりすることは多いでしょう。しかし「遅い原因がCPUにあるのか、メモリ不足なのか、それともディスクI/Oにあるのか」を一度で判断するのは意外と難しいものです。

そんなときに役立つのがvmstatとiostatという2つのコマンドです。vmstatはCPUやメモリ、プロセスの状態を、iostatはCPUとストレージI/Oの状況を数値化して表示してくれるため、サーバー全体のどこに負荷が集中しているのかを見極める手がかりになります。

本記事では、両コマンドの基本操作から出力の読み方、ボトルネックを特定するための実践的な手順までを整理し、実務で役立つ視点を解説します。

vmstatとiostatとは何か

Linuxでサーバーの性能を確認する際に、単にCPU使用率やメモリ消費量を見るだけではボトルネックを特定できないことがあります。

そのような場面で役立つのがvmstatとiostatという2つのコマンドです。これらはシステムの状態を数値化して表示し、負荷の偏りを判断するための重要な手がかりを提供してくれます。

ここでは両コマンドの概要と役割、さらに使い分けのポイントを解説します。

vmstatの概要と役割

vmstat（Virtual Memory Statistics）は、CPU、メモリ、プロセス、スワップ、I/Oの統計情報を表示するコマンドです。

特にメモリやスワップの状態を把握するのに有効で、システムがスワップに依存しているかどうかを確認できます。

また、CPUの利用状況やプロセスの待機状態も出力されるため、負荷がどこに集中しているのかを見極めることが可能です。

vmstat 1 5

このように実行すると、1秒間隔で5回分の統計情報を表示できます。

iostatの概要と役割

iostat（Input/Output Statistics）は、CPUの利用状況とストレージI/Oの統計情報を表示するコマンドです。

ディスクの読み書き性能やI/O待ち時間を数値で確認できるため、ディスクI/Oが原因でシステムが遅くなっているかどうかを調べるのに有効です。

iostat -x 1 5

このように拡張オプション（-x）を付けることで、デバイスごとの詳細なI/O統計を1秒ごとに5回表示できます。

使い分けのポイント

vmstatとiostatは似たようなコマンドに見えますが、得意とする分野が異なります。

vmstatは主にCPUやメモリの状態を把握するのに適しており、iostatはストレージI/Oの詳細な調査に強みを持ちます。

そのため、システム全体のボトルネックを特定する際には、両方のコマンドを組み合わせて利用するのが効果的です。

vmstatの基本操作と読み方

vmstatはLinuxサーバーのCPU、メモリ、プロセス、スワップ、I/Oの状況を一度に確認できる便利なコマンドです。

システムが重いと感じたときに、どのリソースがボトルネックになっているのかを把握するために活用します。

ここでは実行方法から出力項目の読み方、ボトルネック判断のポイントまで解説します。

vmstatコマンドの実行方法

vmstatは引数なしでも実行できますが、通常は更新間隔と回数を指定して利用します。1秒ごとに5回分の統計を確認する例は次の通りです。

vmstat 1 5

[ 出力例 ]

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 31902440 9292 7216664 0 0 0 1 3 1 0 0 100 0 0
0 0 0 31902440 9292 7216664 0 0 0 0 91 131 0 0 100 0 0
0 0 0 31902692 9292 7216704 0 0 0 0 101 153 0 0 100 0 0

この場合、1秒ごとに情報を更新し、合計5行の結果が表示されます。

出力項目の構造

vmstatの出力は複数の項目に分かれており、プロセス、メモリ、CPUなどの情報を同時に確認できます。

プロセス関連（r, b など）

プロセス関連の列は、実行可能状態のプロセス数やブロック中のプロセス数を表します。

メモリ関連（swpd, free, buff, cache など）

メモリ関連の列は、スワップ領域や空きメモリの量を確認できます。

CPU関連（us, sy, id, wa, st など）

CPU関連の列は、ユーザー処理、システム処理、アイドル時間、I/O待ち時間などを示します。

ボトルネック判断のポイント

vmstatの出力を確認することで、システムのどこに問題があるのかを切り分けられます。

このように、vmstatを活用することでシステム負荷の原因を数値から直接把握することができます。

iostatの基本操作と読み方

iostatは、LinuxサーバーのCPU使用率やディスクI/Oの状況を監視するための代表的なコマンドです。

システムのレスポンスが低下したときに「CPUが原因なのか」「ディスクI/Oが原因なのか」を切り分けるために役立ちます。

ただし注意しなければならないのは、iostatの出力内容はオプションによって大きく変化するという点です。

何も指定しない場合と、-cや-xを付けた場合では出力フォーマットが異なるため、記事では必ずオプション別に紹介する必要があります。

デフォルト出力（オプションなし）

オプションを付けずにiostatを実行すると、CPU利用率の平均値と、簡易的なI/O統計（tps、kB_read/s、kB_wrtn/s）が表示されます。

詳細な項目は表示されないため、実務での調査ではあまり使われません。

[root@vec01 ~]# iostat 1 1 Linux 5.14.0-570.12.1.el9_6.x86_64 (vec01) 2025年09月02日 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
32.5 0.00 15.2 8.7 0.00 43.6

Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read kB_wrtn kB_dscd
dm-0 150.0 20480.0 30720.0 0.00 1024000 1536000 0
dm-1 5.0 256.0 128.0 0.00 12800 6400 0
dm-2 10.0 512.0 768.0 0.00 25600 38400 0
nvme0n1 320.0 65536.0 49152.0 0.00 3276800 2457600 0

この出力はシンプルで、システムの大まかな状態を確認する程度に利用します。

CPU利用状況を確認する（-c）

-cオプションを指定すると、CPU利用率だけに絞った出力が得られます。ユーザープロセス、カーネルプロセス、I/O待ち、アイドル率などの内訳を詳細に確認できます。

あなたの環境でも実際にこのフォーマットが出力されたはずです。

[root@vec01 ~]# iostat -c 1 1 Linux 5.14.0-570.12.1.el9_6.x86_64 (vec01) 2025年09月02日 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
68.4 0.00 22.5 7.3 0.00 1.8

この例では、%user が 68.4% と高いため、アプリケーションの処理がCPUを大きく消費しており注意が必要です。

また、%system が 22.5% に達しており、システムコールやI/O処理によるCPU負荷が顕著に出ています。さらに %iowait が 7.3% と比較的高めで、ディスクI/Oの遅延がレスポンス低下につながっている可能性があります。

加えて %idle が 1.8% とほとんど余裕がない状態であるため、このままの稼働が続けばCPUリソース不足による性能劣化が発生する危険性があります。

ディスクI/Oを詳しく見る（-x）

-xオプションを付けると、デバイスごとの詳細なI/O統計が表示されます。どのディスクに負荷が集中しているのか、遅延が発生していないかを調べるのに必須です。

[root@vec01 ~]# iostat -x 1 1 Linux 5.14.0-570.12.1.el9_6.x86_64 (vec01) 2025年09月02日 _x86_64_ (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
45.2 0.00 20.5 8.9 0.00 25.4

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
dm-0 150.0 20480.0 5.0 3.2 45.3 136.5 200.0 30720.0 10.0 4.3 52.7 153.6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 7.5 93.0
dm-1 12.0 768.0 0.0 0.0 6.8 64.0 15.0 896.0 0.0 0.0 7.2 59.7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.3 30.0
dm-2 20.0 1024.0 0.0 0.0 12.3 51.2 25.0 2048.0 0.0 0.0 15.5 81.9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.5 40.0
nvme0n1 420.0 98304.0 15.0 3.5 62.4 230.0 380.0 65536.0 20.0 5.0 71.8 172.4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 12.5 99.7

この出力例では、まず avg-cpu の値に注目する必要があります。%userが45%、%systemが20%と合計でCPUの半分以上を消費しており、アプリケーション処理とカーネル処理の両方で負荷が高まっています。さらに %iowait が8.9%に達しており、ディスクI/O待ちによる遅延が顕著に見られます。その結果、%idleは25%にまで低下しており、CPUに残された余力はわずかです。

次にデバイス統計を確認すると、dm-0 の await が45msと遅延が目立ち、さらに %util が93%と高水準に張り付いており、I/O遅延と高利用率が重なって危険な状態です。

また nvme0n1 はさらに深刻で、%utilが99.7%とほぼ飽和状態にあり、awaitは62msと遅延も顕著です。加えて aqu-sz が12を超えており、I/Oキューに処理待ちが積み上がっている状況です。この状態が継続すれば、システム全体のレスポンスが大幅に低下し、明確なボトルネックとなることは避けられません。

iostat -x の出力を見やすくする方法

`iostat -x` の出力はカラム数が非常に多いため、そのままではどの値がどの項目に対応しているのか瞬時に把握するのは難しいです。特に複数のデバイスが並ぶ環境では、重要な値を見落としてしまうこともあります。そのため実務では、対象デバイスだけを表示するために **grep** を使ったり、必要なカラムだけを抜き出すために **awk** を使ったりするのが一般的です。 例えば「nvme0n1 だけの状況を見たい」ときには以下のように実行します。

iostat -x 1 1 | grep nvme0n1

また「%util や await だけを追いたい」ときには awk を組み合わせて出力を簡潔にします。

iostat -x 1 1 | awk '/nvme0n1/ {print $1, $6, $14, $NF}'

このように出力を絞る工夫を取り入れることで、長大な出力を効率的に監視でき、問題箇所を素早く特定する助けになります。

vmstatとiostatを組み合わせた分析手順

システムのパフォーマンス低下が発生した場合、単一のコマンドだけでは原因を断定できないことが多いです。

vmstatとiostatを組み合わせることで、CPU・メモリ・I/Oといった各リソースの状況を相互に突き合わせ、真のボトルネックを効率的に見抜くことができます。

ここでは代表的な分析手順を紹介します。

CPUボトルネックの見抜き方

CPUの過負荷を疑う場合は、まずvmstatでプロセスの待ち行列やCPU使用率を確認し、次にiostatで%userや%systemの値を確認します。

vmstat 1 5

[ 出力例 ]

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 0 1024000 20000 500000 0 0 5 2 200 300 85 10 5 0 0

ここで「r」が 5 と表示されており、物理CPUコア数（例：4コア）を超えているため、CPU待ちが発生していることが分かります。

次にCPU利用率を詳細に見るためにiostatを実行します。 

iostat -c 1 1

[ 出力例 ]

avg-cpu: %user %nice %system %iowait %steal %idle
82.5 0.0 12.3 1.0 0.0 4.2

• %user = 82.5 → アプリケーション処理がCPUの大半を消費
• %system = 12.3 → システムコール処理も高め
• %idle = 4.2 → 余力がほとんどない

このように rがコア数を上回り、かつ %user や %system が高く、%idleが常に10%未満 の状態が続く場合は、CPUリソース不足がボトルネックであると判断できます。

vmstatの「r」がCPUコア数を大きく超えている場合や、iostatの%userまたは%systemが高止まりしている場合は、CPUボトルネックの可能性が高いです。

メモリ不足の兆候を捉える

メモリ不足はスワップの発生やキャッシュの逼迫として表れます。vmstatで「si」「so」の値が継続的に上昇していないかを確認し、必要に応じてfreeコマンドで残りメモリを確認します。

vmstat 1 5

[ 出力例 ]

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 204800 10240 15000 300000 50 40 20 10 200 300 10 5 80 5 0

• swpd = 204800 → すでに200MBのスワップが使用されている
• si = 50, so = 40 → 1秒ごとにスワップイン・スワップアウトが継続して発生
• free = 10240KB → 実メモリ残量はほとんど残っていない

このように swpdが増加し、si・soが継続的に非ゼロで動き続ける状態 は、物理メモリが足りずディスクへスワップが発生している兆候です。結果としてアプリケーションのレスポンスが極端に遅くなります。

「si」「so」が0で安定していれば問題ありませんが、増加が続けばスワップが発生しておりパフォーマンス低下の要因になります。

ディスクI/O遅延の特定方法

I/O遅延はシステム全体のレスポンス低下に直結するため、iostatでの確認が有効です。

iostat -x 1 1

[ 出力例 ]

Linux 5.14.0-570.12.1.el9_6.x86_64 (vec01) 2025年09月02日 x86_64 (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
18.2 0.0 12.5 8.5 0.0 60.8

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz aqu-sz %util
sda 120.0 20480.0 5.0 3.5 42.5 170.6 150.0 30720.0 10.0 4.0 55.8 204.8 7.8 92.3
nvme0n1 400.0 98304.0 15.0 3.7 65.2 245.8 380.0 65536.0 20.0 5.0 72.1 172.4 12.5 99.6

• sda
  • r_await = 42.5ms、w_await = 55.8ms → 数十msの遅延が発生
  • %util = 92.3% → デバイスがほぼ飽和状態
• nvme0n1
  • r_await = 65.2ms、w_await = 72.1ms → I/O要求処理が明らかに遅延
  • aqu-sz = 12.5 → キューに処理待ちが積み上がっている
  • %util = 99.6% → 完全にリソースが枯渇し、ボトルネック状態

このように、awaitが数十msを超えて継続し、%utilが90%以上で推移している場合は、ディスクI/Oがシステムの性能低下の原因であると判断できます。

出力のawaitが数十ms以上に増え、%utilが90%以上で推移している場合はディスクがボトルネックになっている可能性が高いです。対象デバイスをgrepで絞って確認すると、さらに分かりやすくなります。

複合的なトラブルの切り分け方

実際のトラブルはCPU・メモリ・ディスクのどれか一つではなく、複数の要因が連鎖して発生するケースが多いです。そのため、vmstatとiostatを突き合わせて状況を整理することが重要です。

vmstat 1 5

出力例（メモリ不足＋I/O遅延を伴う状態）：

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 512000 2048 12000 200000 100 80 200 150 300 500 15 10 60 15 0

• swpd = 512000、si/so が継続的に非ゼロ → スワップが多発している
• r = 2, b = 1 → プロセスがCPU待ちとI/O待ちで詰まっている
• wa = 15% → CPUがI/O待ちでブロックされている

次にiostatを確認します。

iostat -x 1 1

出力例（同時にストレージ遅延が発生している状態）：

Linux 5.14.0-570.12.1.el9_6.x86_64 (vec01) 2025年09月02日 x86_64 (8 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
18.2 0.0 12.5 8.5 0.0 60.8

Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz aqu-sz %util
sda 120.0 20480.0 5.0 3.5 42.5 170.6 150.0 30720.0 10.0 4.0 55.8 204.8 7.8 92.3
nvme0n1 400.0 98304.0 15.0 3.7 65.2 245.8 380.0 65536.0 20.0 5.0 72.1 172.4 12.5 99.6 

• sda: r_await=42.5ms, w_await=55.8ms、%util=92.3% → I/O遅延が顕著でデバイスが飽和に近い
• nvme0n1: r_await=65.2ms, w_await=72.1ms、aqu-sz=12.5、%util=99.6% → 完全にボトルネック状態

このように、vmstatでは スワップ発生（si/so増加）とiowait上昇 が見られ、iostatでは awaitの上昇と%utilの飽和 が同時に確認できます。

これらを突き合わせることで、下記のように切り分けることができます。

• 根本原因 → メモリ不足によるスワップ多発
• 二次的影響 → ディスクI/O増加で待ち時間増加 → CPUがiowaitでブロック

効率的な運用のためのTips

vmstatやiostatはトラブル対応時に有効ですが、日常的な監視や運用を考えると、それだけでは十分ではありません。より効率的にシステムを管理するためには、他ツールとの併用や監視の仕組み化、アラート設定が重要です。ここでは運用の現場で役立つ工夫を紹介します。

sarやdstatなど他ツールとの比較

vmstatやiostatは瞬間的な状況を把握するのに適していますが、長時間の傾向を把握するにはsarやdstatといったツールが有効です。

このように、vmstatやiostatが「詳細な瞬間値の確認」に強いのに対して、sarやdstatは「履歴や全体の傾向把握」に強みがあります。用途に応じて使い分けることが効率的です。

定期監視に取り入れる方法

トラブル発生時だけではなく、日常的な監視に取り入れることで異常を未然に防ぐことができます。cronに登録して定期的に実行し、ログに蓄積しておくと便利です。

crontab -e

例：5分ごとにiostatを記録する場合

*/5 * * * * /usr/bin/iostat -x >> /var/log/iostat.log 2>&1

このように定期的に収集しておけば、過去の状態と比較することで問題発生の兆候をつかむことができます。

Beエンジニア

Beエンジニア

https://www.pmi-sfbac.org/linux-crontab-usage

自力で生きる方法を探すために、ITで仕組みを作る基礎を発信するブログ。

アラート設定の考え方

監視値を収集するだけでは不十分で、一定のしきい値を超えたら通知する仕組みを作ることが重要です。

このような条件をしきい値として設定し、メールや監視システムに連携することで、トラブルを早期に検知できます。しきい値はシステム特性や利用状況に合わせて調整し、誤検知や見逃しがないように運用することが求められます。

▶︎ この記事を読んだら、次は 「sarコマンドでサーバー性能を長期監視する方法」 を読むのがおすすめです！

Beエンジニア

【Linuxの基礎知識】sarコマンドでサーバー性能を長期監視する方法

https://www.pmi-sfbac.org/linux-sar-usage

「サーバーが重いけど、原因がどこにあるのか分からない…」そんな経験はありませんか？　CPUなのか、メモリ不足なのか、それともディスクI/Oやネットワーク帯域の問題なのか・・・サーバーの性能トラブルを突き止めるには、瞬間的な状態ではなく、時間の経過による変化を追いかけることが重要です。そんなときに役立つのが「sarコマンド」です。sarはLinuxに標準的に導入されることが多い「sysstat」パッケージに含まれており、CPUやメモリ、ディスク、ネットワークといったリソース利用状況を定期的に収集・記録してくれる便利なツー...