ロードアベレージが高いと連絡を受け、その数字が本当に危険なのかを落ち着いて確かめようとしている一人運用の保守担当者
障害対応・運用監視約10分

「サーバーのロードアベレージ、8 まで行ってます。大丈夫ですか？」——監視の担当者や同僚から、そんな連絡が入る。数字を見た瞬間、「8 って高いよな……」とドキッとして、とりあえずサーバーにログインする。でも、いざ uptime を叩いて三つ並んだ数字を眺めても、「これって、結局まずいの？まだ平気なの？」の判断がつかない——。

ロードアベレージは、保守運用でいちばん誤解されやすい数字のひとつです。名前に「ロード（負荷）」と付いているので、「大きい＝危険」と感じてしまいますが、実際にはその数字を単体で見ても、危ないかどうかは決まりません。同じ「8」でも、まったく問題ない場合と、すぐ手を打つべき場合の両方があります。

この記事では、あの三つの数字が本当は何を表しているのか、どう見比べれば「今のうちのサーバーにとって高いのか」が分かるのかを、一緒に順番に整理していきます。専門用語も出てきますが、そのつど嚙みくだくので、身構えなくて大丈夫です。

結論：見るのは「数字の大きさ」ではなく「コア数との比」と「向き」

先に結論からお伝えします。ロードアベレージを見たら、確認するのは次の3つです。

  1. CPUのコア数（nproc で分かる）と、ロードアベレージを見比べる。だいたい「ロード ÷ コア数」が 1 を超えているかが目安。
  2. 三つの数字の向き（1分・5分・15分）。左（直近）が右（過去）より大きいなら上がっている途中、小さいならもう収まりかけ。
  3. 実際にサイトが遅い・エラーが出ているか。ロードが高くても、体感の遅さや障害が出ていなければ、あわてて何かする必要はありません。

つまり「8 だから危険」ではなく、「8コアのサーバーでロードが 8 なら、ちょうど使い切っているくらい」「4コアのサーバーでロードが 8 で、しかも上がり続けていて、実際に重い」なら手を打つ、という見方をします。数字そのものより、自分のサーバーの大きさと見比べることが肝心です。

そもそもロードアベレージって何を数えているの？

uptime や top の右上に出てくる、load average: 1.15, 0.90, 0.75 のような三つの数字。これは左から直近1分・5分・15分の平均を表しています。

ではこの「平均」が何の数かというと、ざっくり言えば「その瞬間に、仕事の順番待ちをしていたプロセスの数」の平均です。もう少し正確に言うと、Linux では次の2種類のプロセスを数えています。

ここが Linux 特有で大事なところです。ロードアベレージは「CPUの忙しさ」だけでなく、「ディスクの読み書き待ちで固まっているプロセス」も含めて数えています。だから、CPU使用率が低いのにロードだけ高い、という状況が起こり得ます。これは「CPUは暇だけど、みんなディスクの応答を待って行列している」状態です。

ロードアベレージが「CPUを使う・待つプロセス」と「ディスク待ちで止まっているプロセス」の両方を数えていることを示した図
ロードアベレージは「CPU待ちの行列」だけでなく「ディスク待ちの行列」も一緒に数えている

イメージとしては、レジの行列に似ています。レジ（CPUのコア）が何台あるかで、同じ行列の長さでも「まだ余裕」か「さばききれていない」かが変わりますよね。ロードアベレージは「行列に並んでいる人数」で、レジの台数＝コア数と見比べて初めて意味を持つ、というわけです。

「高い」の基準はコア数で決まる

だからこそ、最初に確認したいのがCPUのコア数です。次のコマンドで分かります。

nproc

これで返ってきた数字が、そのサーバーが同時にさばける「レジの台数」です。lscpu や cat /proc/cpuinfo でも確認できます。

コア数が分かれば、目安はシンプルです。

たとえば、

同じ「8」でも、意味がまるで違うのが分かると思います。「8 は危険」と一言では言えない理由が、ここにあります。

三つの数字は「向き」で読む

もうひとつ、三つ並んでいることには意味があります。左から1分・5分・15分なので、時間の流れ（トレンド）が読めます。

一瞬だけ跳ねた（1分値だけ高い）のか、ずっと高止まりしているのかで、対応の急ぎ具合が変わります。瞬間の値より、向きと継続を見てあげてください。

「高いのに問題ない」と「本当にまずい」の見分け方

ここが、いちばん知りたいところだと思います。ロードが高いとき、次の順で見ると落ち着いて判断できます。

ロードが高いときに「コア数と比べる・向きを見る・体感を確かめる」の順で危険度を見分ける流れの図
「コア数と比べる → 向きを見る → 実害があるか」の順で見れば、あわてずに判断できる
  1. コア数と比べる：ロード ÷ コア数 が 1 前後までなら、そもそも過負荷ではありません。ここで「うちのコア数だと、この数字はフル稼働手前だな」と分かれば、大きさへの過剰な不安はほぐれます。
  2. 向きを見る：上がり続けているのか、収まりかけているのか。収束傾向なら、見守りで足りることも多いです。
  3. 実害を確かめる：いちばん大事なのはこれです。サイトの応答が実際に遅いか／エラーが増えているか／監視の外形チェックが失敗しているか。ロードが高くても、利用者に影響が出ていなければ、それは「よく働いている」だけかもしれません。

逆に「本当にまずい」のは、コア数の何倍もの行列ができていて、しかも上がり続けていて、実際にサイトが重い／落ちている——この3つが重なったときです。そのときは、top でCPUを食っているプロセスを探すのか、ディスクI/O待ちを疑うのかへ進みます。

「ロードが高い＝CPUが原因」と決めつけないのもポイントです。前に書いたとおり、ロードにはディスク待ちも含まれます。CPU使用率（top の %us／%sy）が低いのにロードだけ高いなら、犯人はCPUではなくディスクや外部応答の待ちかもしれません。切り分けの順番は、CPU使用率の記事のほうで詳しく整理しています。

明日やること：平常時の値を一度メモしておく

ロードアベレージがいちばん役に立つのは、実は障害のときより「ふだんの値を知っているとき」です。あなたのサーバーの平常時のロードが「だいたい 0.5〜1.5 くらい」と分かっていれば、それが 5 に跳ねた瞬間に「いつもと違う」と気づけます。基準（ベースライン）があってはじめて、異常が異常として見えます。

明日、気になっているサーバーで一度だけ、次を確認してみてください。

この2つを運用メモに1行残しておくだけで、次に「ロードが高いです」と言われたとき、あわてずに「うちの平常値と比べてどうか」で判断できるようになります。

チェックリスト：ロードアベレージを見たとき

よければ、こちらも

ロードアベレージは、「サーバーのどこかが混み始めている」サインのひとつです。同じ“重い・遅い”を切り分ける手順や、逼迫を前もって拾う監視の考え方も、あわせて型にしておくと落ち着けます。

ロードアベレージの読み方が分かり、数字の大きさに驚かなくなって落ち着いている保守運用の担当者

「ロードが 8 です」と言われて、以前はドキッとしていた数字も、コア数と見比べて、向きを見て、実害を確かめる——この順番さえ持っておけば、もう闇雲に不安になることはありません。 今日はまず、気になっているサーバーで nproc と uptime を一度だけ叩いて、「うちの平常値」を1行メモするところから始めれば十分です。ふだんを知っている人が、いちばん早く異常に気づけます。数字の意味が分かった時点で、もう対応は前に進んでいます。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語