ロードアベレージの正体 — CPU 使用率と違う点

インフラ Linux パフォーマンス
読了 5分

uptime が見せる三つの数字、ロードアベレージは、Linux で最も有名で最も誤読される指標です。「1.0 を超えたら危険」「CPU 使用率のようなもの」といった半分だけ正しい通念が多いのです。この記事はこの数字の正確な定義と、CPU 使用率と食い違う典型的な事例を整理します。ハードウェア中級 #1 で指標全般を扱ったので、ここではロードアベレージ一つを最後まで掘り下げます。

uptime 
$ uptime
 14:32:07 up 213 days,  4:11,  1 user,  load average: 6.12, 4.35, 2.08

定義 — 実行中 + 実行待ち + ディスク待ち #

Linux のロードアベレージは、次のタスク数の指数移動平均です。

  • 実行中(R): いま CPU コアの上で動いているタスク
  • 実行待ち(R): 準備はできたのにコアが空くのを待つタスク — サーバーが遅い理由 #1 で見た run queue です
  • 割り込み不可の待ち(D): 主にディスク I/O の完了を待って眠るタスク

三つ目の項目が肝であり罠です。他の Unix 系と違い、Linux はディスクを待つタスクまでロードに数えます。 だから Linux のロードアベレージは「CPU の負荷」ではなく「CPU またはディスクを待つ需要」に近いのです。CPU が暇でもディスクが詰まればロードは跳ね上がります。なお一般の待ち(ネットワークの応答、ロック、sleep)は S 状態なのでロードには入りません。

読む基準 — 絶対値ではなくコア数との比 #

「1.0 なら危険」はコアが 1 個だった時代の基準です。ロードは需要の個数なので、供給(コア数)と比べてこそ意味が生まれます。

  • ロード ≈ コア数: 供給と需要がほぼ合っている状態です。16 コアのサーバーのロード 14 は健全な満席です。
  • ロード ≪ コア数: 余裕があります。
  • ロード ≫ コア数が持続: タスクが行列を作っています。CPU のせいかディスクのせいかは、この数字だけでは分かりません(下で見分けます)。

コア数は nproc で確認します。コンテナの中ならもう一つ注意が要ります。ロードアベレージはホスト全体の値なので、コンテナの CPU 制限と無関係に、隣の負荷まで混ざって見えます。

CPU 使用率と食い違う四つの典型 #

ロードアベレージと CPU 使用率は違うものを測るので、食い違いの組み合わせごとに診断が違います。

使用率ロード典型的な原因
高い≈ コア数正常な演算の飽和。需要が供給を少し超える状態
低い高いディスクのボトルネック — D 状態のタスクがロードを押し上げる。NFS の応答停止が極端な例
高い≫ コア数CPU の過剰な需要。スレッド・ワーカー数がコアに対して過剰なケースを含む
低い低いのに遅いロードに映らない待ち(ロック、ネットワーク、アップストリーム)。第 1 編の領域

特に二つ目の組み合わせが Linux 固有の罠です。「CPU は 5% なのにロードが 40」のサーバーは CPU の問題ではなくストレージの問題で、NFS サーバーが応答を止めると、そのマウントに触れるタスクが軒並み D 状態で溜まってロードが数百まで跳ねる、おなじみの場面が生まれます。ロードが高いときに D 状態をすぐ確認するコマンドはこうです。

D 状態タスクの確認 
$ ps -eo state,pid,wchan:30,comm | awk '$1=="D"'
D  8123 rpc_wait_bit_killable  backup-agent
D  8124 rpc_wait_bit_killable  backup-agent

wchan(何を待って眠っているか)まで見えるので、ディスクなのか NFS なのかまで一度に絞り込めます。

1 分、5 分、15 分 — 三つの値はトレンドのためにあります #

三つの値はそれぞれ直近 1 分、5 分、15 分の指数移動平均です。個々の値より比較が情報です。

  • 1 分 ≫ 15 分(例: 12, 4, 2): 負荷がいままさに上がっている最中です。始まったばかりの何か(デプロイ、バッチ、トラフィックの急増)を探します。
  • 1 分 ≪ 15 分(例: 2, 6, 14): 負荷が抜けている最中です。終わったばかりの出来事の後始末の局面です。
  • 三つが同じように高い: 高止まりの状態です。一時的なスパイクではなく、容量またはボトルネックの問題です。

監視のアラートを設定するなら、瞬間のスパイクに強い 5 分の値の基準が無難で、しきい値は絶対値ではなくコア数に対する倍率(例: コア数の 1.5 倍が持続)で設定してはじめて、サーバーのスペックが変わってもアラートが有効に残ります。

診断手順のまとめ #

ロードが高いというアラートを受けたときの手順です。

  1. コア数との比に換算します。 nproc に対して何倍かから、そして 1・5・15 分の比較で、上がっている最中か高止まりかを見ます。
  2. CPU 使用率と突き合わせます。 使用率も高ければ CPU の需要、使用率が低ければ D 状態を疑います。
  3. D 状態を数えます。 ps で D 状態のタスクと wchan を見て、ディスク・NFS 側なら iostat の診断へ進みます。
  4. CPU 側なら run queue の診断へ — vmstat の r、プロセス別の CPU 消費ランキングの確認へ進みます。道具全般は RHEL 上級 #3 で扱いました。

まとめ #

  • Linux のロードアベレージは、実行中 + 実行待ち + ディスク待ち(D 状態)のタスク数の移動平均です。CPU 使用率とは違うものを測ります。
  • 絶対値ではなくコア数との比で読みます。16 コアのロード 14 は満席であって過負荷ではありません。
  • 使用率が低いのにロードが高ければ、ディスク(特に NFS)の D 状態の滞留を疑い、ps の state・wchan で確認します。
  • 1・5・15 分の三つの値はトレンド用です。上がっている最中か、抜けている最中か、高止まりかをまず見分けます。
  • アラートのしきい値はコア数に対する倍率で取ります。絶対値の基準はサーバーのスペックが変われば無意味になります。
X