この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
新人時代の私は、この数字を見るたびに本気で焦っていました。
Linuxを学び始めると、topやuptimeで表示されるload average（負荷平均）という数字に振り回された経験がある方は少なくないはずです。数字が大きいほど危険だと思い込み、根拠のないまま再起動やプロセスの強制終了に走ってしまう。私自身、SE時代にまさにそれをやって上司に止められた経験があります。
この記事では、20年以上Linuxサーバーを運用してきた経験と、セミナーで3,100名以上を指導してきた立場から、load averageという数字を「正しく読む」ための考え方を、当時の失敗も含めて正直にお伝えします。
この記事のポイント
・load averageは「数字の大小」ではなく「コア数との比率」で読む
・nprocでコア数を確認しないと、その数字は正しく評価できない
・load averageが高くてもCPUがiowaitで待っているだけの場合がある
・「サーバーが重いのにCPUは空いている」時はI/Oと同時実行数を疑う
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
新人時代、load averageの数字を見るたびに手が震えていた理由
2003年頃、私は社内のLinuxサーバー管理を任されたばかりのSEでした。障害対応の当番になった夜、監視ツールのアラートで「load average 5.2」という通知が届いたことがあります。当時の私はその数字が何を意味するのか正確に理解しないまま、「5」という数字だけを見て「サーバーが限界を超えている」と判断し、慌てて重そうなプロセスをkillしようとしました。たまたま先輩が隣にいて「そのサーバー、コア何個か知ってるか」と聞かれ、答えられませんでした。先輩は落ち着いた口調で「コアが8個あるサーバーなら、5なんて全然余裕だ」と教えてくれました。私はそのとき初めて、load averageという数字を単体で評価することの危うさを知りました。
セミナーで3,100名以上を指導してきた中で、同じ勘違いをしている受講生を何度も見てきました。「load averageが1を超えたら危険」というような、根拠のあいまいな基準だけが独り歩きしているケースが本当に多いのです。
「load averageは高いほど危険」という思い込みが崩れた日
先輩に教わってから、私は初めてload averageの定義をきちんと調べ直しました。load average（負荷平均）とは、実行待ち状態（実行中またはCPU割り当て待ち）にあるプロセス数の平均値であり、直近1分・5分・15分の3つの数値で表示されます。重要なのは、この数字が「CPU使用率（パーセント）」とは別物だという点です。CPU使用率が100%に張り付いていなくても、load averageが高くなることがあります。逆にCPU使用率が低くても、ディスクI/O待ちのプロセスが多ければload averageは上昇します。
# nproc 8 # uptime 14:32:05 up 21 days, 3:14, 2 users, load average: 5.21, 4.87, 3.90
数字だけを見て一喜一憂するのではなく、「そのサーバーに何個コアがあるか」を必ずセットで確認する。これが、私が新人時代の失敗から学んだ一番の教訓です。
コア数を基準に読む、load averageの正しい見方
実際にサーバーの負荷状況を判断するときは、次の3ステップで見るようにしています。1. まずnprocでコア数を確認する
load averageの数字を見る前に、必ず対象サーバーのコア数を確認します。仮想サーバー（VPSやクラウドインスタンス）では、契約プランによってコア数が異なるため、思い込みで判断するのは危険です。・nproc：現在のプロセスが利用可能な論理CPU数を表示（コンテナ環境ではcgroupの制限値が反映される場合がある）
・lscpu：物理コア数・論理コア数・ソケット数などを詳細に表示
2. load averageの3つの数字が示す時間軸を読む
uptimeの出力にある3つの数字は、それぞれ直近1分・5分・15分の平均です。この3つを比較することで、負荷が「今まさに上がっている最中」なのか「ピークを越えて落ち着きつつある」のかが分かります。・1分値が5分値・15分値より大きい → 負荷が上昇中（これから重くなる可能性）
・1分値が5分値・15分値より小さい → 負荷は収まりつつある（ピークは過ぎた）
【重要】「コア数×1」を超えたら要注意という基準
一般的な目安として、load averageが「コア数と同じ値」を超えると処理待ちが発生し始めている状態、「コア数の2倍」を超えると明確に処理能力が不足している状態と判断されることが多いです。ただしこれはあくまで目安であり、ワークロードの性質（CPU中心かI/O中心か）によって体感の重さは変わります。数字だけを鵜呑みにせず、実際のレスポンス状況と合わせて判断するのが鉄則です。現場で実際にあった「数字は高いが問題なし」だったケース
講師として現場のトラブル相談を受ける中で、load averageの数字だけを見て慌ててしまう相談を数多く受けてきました。実務でよくあるのが、CPUではなくディスクI/O待ちが原因で数字が上がっているケースです。# vmstat 1 3 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 6 4 0 102340 81200 512300 0 0 1200 3400 1800 2600 8 4 12 76 0 5 3 0 101980 81180 511900 0 0 1150 3300 1750 2550 7 4 13 76 0 6 4 0 101720 81160 511500 0 0 1280 3550 1820 2610 9 5 11 75 0
「サーバーの反応が重いのにCPUは空いている」というトラブルの切り分け手順
現場でよく相談されるのが、「load averageが高くて心配なのに、topを見るとCPU使用率はそれほど高くない」という状態です。私が実際にセミナーで教えている切り分け手順を紹介します。・まず
vmstat 1 5を実行し、wa（iowait）列が高くないか確認する・waが高い場合は
iostat -x 1 3でディスクごとのI/O使用率（%util）を確認する・waが低くCPU使用率（usまたはsy）が高い場合は
topで該当プロセスを特定する・同時実行中のプロセス数が異常に多い場合は、cronやバッチ処理の同時実行設定を疑う
本番サーバーでこの切り分けを怠って、原因がCPUだと思い込んだままプロセスをkillしてしまうと、実行中だったバッチ処理が中断し、二次的な障害を招く恐れがあります。焦って手を動かす前に、まずwaの数値を確認する。これは運用の基本であり、今も私自身が現場で必ず守っている手順です。
まとめ
load averageは、コア数という前提を無視して数字だけを見ると、正しく判断できません。| 状況 | 確認すべきこと |
|---|---|
| load averageの数字だけで不安になったとき | nproc でコア数を確認し、数字をコア数で割って評価する |
| 負荷の推移を知りたいとき | uptime の1分・5分・15分値を比較する |
| CPUが空いているのに重いとき | vmstat 1 5 でiowait（wa列）を確認する |
| ディスクがボトルネックか調べたいとき | iostat -x 1 3 でディスクごとの使用率を確認する |
新人時代の私は、load averageという数字の意味を理解しないまま、感覚だけで「危険」と判断していました。20年以上サーバーを運用してきた今だからこそ言えますが、数字に振り回されるかどうかは、知識の有無で決まります。
「怖い数字」を「読める数字」に変えることは、Linuxサーバー運用の中でも特に効果の大きい学びのひとつです。落ち着いてコア数を確認し、iowaitを疑う。この習慣を身につけるだけで、障害対応での焦りは大きく減らせます。
関連記事として、Linuxのポート確認コマンド（ss・lsof）やchkconfig・systemctlの使い方も、障害対応の基礎として参考にしてみてください。
数字に振り回されないLinux運用の「型」、体系的に学んでみませんか？
load averageに限らず、Linuxサーバーの運用トラブルの多くは「基準を知らないまま判断してしまう」ことが原因です。まずは全体像を体系的に掴んでください。
ネットの断片情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Linuxの参考書を何冊読んでも実力がつかない理由｜現役講師が語る「読む勉強」と「使える力」の差
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます