この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
現場で一番ふわっとした依頼が、この一言です。何が遅いのか、いつから遅いのか、どれくらい遅いのかが抜けたまま、とにかく何とかしてくれと投げられる。
正直に白状すると、私も駆け出しの頃はこの一言にパニックになって、いきなりtopを叩いて「CPUは高くないですね」で止まってしまい、上司に呆れられた記憶があります。何年も経ってから、あれは「切り分けの順番を知らなかっただけ」だと気づきました。
この記事では、20年以上サーバーを運用してきた経験から、「遅い」と言われた時に現役講師がまず確認する5つの指標を解説します。個別コマンドの解説ではなく、どの順番で何を見るかという思考の型をまとめました。
この記事のポイント
・「遅い」の正体はCPU・メモリ・ディスク・NW・アプリの5層にある
・uptime、vmstat、iostatの3本で8割の切り分けができる
・切り分け思考が身につくと報告の質も一段上がる
・指標を読む訓練は小さな検証環境の反復でしか身につかない
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ「遅い」をいきなり解決しようとしてはいけないのか
ここが一番の落とし穴です。依頼者が「遅い」と言った瞬間に、ベテランほどすぐ対処に走りません。理由は単純で、「遅い」には原因の層が複数あり、先に層を特定しないと効く手が打てないからです。
私が受講生からよく聞かれる質問が、「まずtopを叩けばいいんですよね？」というものです。気持ちはわかるのですが、topはあくまでCPUとプロセスの断面を見る道具で、ディスクIOやネットワーク遅延はほとんど見えません。topだけを頼りにすると、CPU負荷が低いという情報だけで「サーバーは元気です」と報告してしまい、後で大恥をかきます。
切り分けは、必ず「どの層で詰まっているか」を先に特定する作業です。
現役講師がまず確認する5つの指標
順番に意味があります。上から順に見ることで、次に何を調べるかが自然に決まります。1. ロードアベレージ（uptime）で全体の混み具合を掴む
最初に叩くのはuptimeです。topでもいいのですが、topは情報量が多すぎて焦点がぼやけます。# check load average $ uptime 14:32:05 up 42 days, 3:17, 2 users, load average: 4.82, 3.91, 2.14
CPUコア数を超える値が継続していれば、何かがCPU待ちで詰まっているサインです。ここで重要なのは「瞬間値で判断しない」こと。1分が高くて15分が低ければ直近だけの現象、逆なら慢性的な詰まりです。
私も受講生にはまずここを見る癖をつけてもらいます。topより先に、全体像を1行で掴む。これが切り分けの入り口です。
2. CPU使用率と使われ方（vmstat）で原因の層を絞る
ロードアベレージが高い時、次に見るのはvmstatです。# 2秒間隔でCPU・メモリ・IO状況を表示する $ vmstat 2 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 3 2 0 124532 54128 892416 0 0 3128 284 852 1421 18 22 48 12 0
・wa（I/O待ち）が高い：CPUが暇なのにディスクを待っている。ディスクが犯人の可能性大
・b（ブロックされたプロセス数）が継続的に多い：何かがI/Oで詰まっている
・us（ユーザーCPU）が高い：アプリケーション側の処理が重い
・sy（システムCPU）が高い：カーネル側、つまりシステムコール多発や割り込み過多
「遅い」の正体がCPUなのかディスクなのか、vmstatの1画面でかなり絞れます。
3. ディスクI/O（iostat）で本当に詰まっている装置を特定する
waが高いと出たら、次はiostatで装置を特定します。# 拡張情報付きで2秒間隔表示（sysstatパッケージが必要） $ iostat -x 2 3 Device r/s w/s rMB/s wMB/s await %util sda 12.0 88.3 0.12 4.21 38.50 94.20
・await：I/O要求が完了するまでの平均ミリ秒。数十ms以上続くと明確に遅い
・%util：装置の稼働率。80%を超えると詰まり気味、100%に張り付けばほぼ飽和
私が現場でよく見かけるのが、ディスクが物理的に古くなっていたり、バックアップジョブがバックグラウンドで走り続けていて%utilが100%に張り付いているパターンです。この場合、アプリやCPUをいくら見ても原因は出てきません。
4. メモリとスワップ（free）で見かけ倒しでないかを確認する
次はメモリです。# メモリ使用状況を人間が読める単位で表示 $ free -h total used free shared buff/cache available Mem: 15Gi 4.2Gi 320Mi 88Mi 10Gi 10Gi Swap: 2.0Gi 820Mi 1.2Gi
Linuxは空いているメモリを積極的にキャッシュ（buff/cache）に使うので、freeが小さく見えても実際には足りていることが多いです。ここで判断に使うのは「available」の値と、スワップがどれくらい使われているかです。
availableが極端に少なく、スワップの使用量が徐々に増えているなら、メモリ圧迫でスワップアウトが起きており、これはvmstatのsi/so列にも現れます。スワップに追い出された瞬間、体感速度は一気に落ちます。
5. ネットワーク（ss、ping、traceroute）で外側との接続を疑う
ここまでで原因が見えない時、最後にネットワークを疑います。# 接続中のTCP状態をサマリ表示 $ ss -s Total: 245 TCP: 182 (estab 38, closed 120, orphaned 0, timewait 118) # 外向きの疎通と遅延を確認する $ ping -c 3 www.example.com # 経路のどこで遅延しているかを追う $ traceroute www.example.com
Webサーバーで「遅い」と言われる場合、ローカルは全部正常なのにDNSの引きが遅い、上流ネットワークで詰まっている、というパターンも珍しくありません。サーバーの中だけを見ていては絶対に見えない層です。
切り分けの順番が報告の質を決める
5つの指標を順番に見ることには、もう一つ大きな意味があります。そのまま報告の順番になるからです。
上司や顧客に「遅かった原因」を説明する時、「ロードアベレージはこうでした、CPUはこれ、ディスクがこの数値でした、だから原因はディスクIO飽和です」と順に積み上げて説明できると、相手は納得します。逆にいきなり「ディスクだと思います」と結論だけ話すと、根拠を聞かれて答えられず信頼を失います。
切り分けの型を持っているエンジニアは、報告の型も自然と持てるようになります。これは現場で評価される人の共通点だと思います。
現場でハマりやすいトラブルと注意点
指標の見方を覚えても、現場では思わぬ落とし穴があります。私が実際にやらかした例と、受講生によく指摘する【重要】な注意点をまとめます。・iostatがインストールされていない：sysstatパッケージが入っていない本番環境は珍しくありません。緊急時に慌てないよう、日頃から検証機で存在確認をしておくのが鉄則です
・ロードアベレージが高いのにCPUは暇：このパターンはほぼ100%ディスクI/O待ちです。vmstatのwaとiostatの%utilを並べて読めば即判断できます
・freeの見かけ不足でスワップを疑いすぎる：availableが十分ならメモリは足りています。buff/cacheを誤解したまま報告すると恥ずかしい思いをします
・長時間の統計コマンドを本番で連発する禁止行為：iostat -x 1を延々と流すとsysstatのログが肥大化します。本番では間隔と回数を必ず指定する癖をつけてください
「注意」で済む話ばかりですが、現場の信頼はこういう細部で積み上がります。
指標を読む力は小さな検証環境でしか育たない
正直に告白すると、私は最初の3年間、この切り分けがほとんどできませんでした。本で読んでも、ハンズオン研修を受けても、身につかなかったのです。転機になったのは、自宅で中古のPCサーバーを1台譲り受けて、自分専用のLinux検証環境を持った時でした。
わざと大きなファイルをddで書き続けてiostatの%utilが100%に張り付く様子を見たり、無限ループのシェルスクリプトを流してロードアベレージが急上昇する瞬間を目撃したり、stressツールでメモリを圧迫してスワップアウトが起きる状況を再現したり。数値と現象を自分の手で結びつける作業を何度も繰り返しました。
これをやった後に本番サーバーで数値を見ると、「ああ、これは先週自分の検証環境で見たあの状態だ」と瞬時にピンとくるようになりました。指標を読む力は、座学や読書では身につかないと思います。実機で数値を動かした経験の回数がすべてです。
まとめ
「遅い」と言われた時に見るべき5つの指標を整理します。| 順番 | 指標 | 使うコマンド |
|---|---|---|
| 1 | 全体の混み具合 | uptime |
| 2 | CPU使用率とI/O待ち | vmstat 2 5 |
| 3 | ディスクI/Oの詰まり | iostat -x 2 3 |
| 4 | メモリとスワップ | free -h |
| 5 | ネットワーク接続 | ss -s |
指標を読む力、切り分けの順番、そして報告の組み立て方。この3つが揃ったエンジニアは、現場で確実に信頼されます。駆け出しの頃の私が呆れられたのは、この順番を知らずにいきなり結論を探しに行ったからでした。
順番を知っているだけで、現場での見え方は大きく変わります。
現場で通用する切り分け思考と運用の「型」を身につけたいと思いませんか？
uptime、vmstat、iostat。個別のコマンドはネットに転がっていても、「現場でどう順番に見るか」という思考の型は、なかなか体系化されていません。
断片情報をつなぎ合わせて独学するよりも、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：アフターコロナのIT業界について
- この記事の属するカテゴリ：ITエンジニアへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます