飽和とサチュレーション信号の検知

利用率だけでは飽和は見えない

性能監視で最もよく使われる指標は 利用率（utilization） です。CPU使用率、ディスクビジー率、コネクションプール占有率——いずれも「資源が稼働していた時間の割合」を平均したものです。しかし利用率には致命的な弱点があります。利用率は飽和の手前で頭打ちになり、その先の劣化を予告しない のです。

利用率の定義上の上限は100%です。一度100%に張り付くと、それ以上の情報を返しません。ところが現実の応答時間は、利用率が100%に届く前から急峻に悪化し、100%に達した後もさらに悪化し続けます。この「利用率では見えない領域」を直接捉えるのが 飽和（saturation） ——待ち行列に積まれた仕事の量です。

Brendan Gregg が提唱した USE法（Utilization / Saturation / Errors）が利用率と飽和を別軸として並べるのは、この両者が測っているものが本質的に違うからです。利用率は「どれだけ忙しいか」、飽和は「どれだけ捌ききれず溜まっているか」を表します。

なぜ利用率が遅行指標になるのか

利用率が劣化を予告できない理由は、待ち行列理論の応答時間式から原理的に導けます。到着がランダム（ポアソン的）な単一サーバーの待ち行列（M/M/1）では、利用率を ρ とすると平均応答時間は次のように振る舞います。

平均応答時間 ∝ 1 / (1 - ρ)

ρ が 0.5 のとき分母は 0.5、ρ が 0.9 のとき分母は 0.1、ρ が 0.99 のとき分母は 0.01。つまり利用率が 0.9 から 0.99 へ「わずか9ポイント」上がるだけで、応答時間は約10倍に膨らみます。利用率の目盛りはほぼ平坦に見えるのに、その裏で待ち行列と応答時間は爆発しているのです。詳しくは/devops/queueing-theory-tail-latency/を参照してください。

ここに 平均 の罠が重なります。利用率を1分平均で取ると、その1分の中に「100%で詰まった瞬間」と「暇な瞬間」が混在しても、平均は中庸な値に丸められます。バースト的な飽和は平均化で消えますが、待ち行列はその瞬間に伸び、ユーザーは待たされています。飽和は瞬間値（あるいはキュー長そのもの）で見ないと意味がない のは、このためです。

load average の誤解

Linuxの load average は飽和指標として広く使われますが、最も誤解の多い数字でもあります。これは「CPU使用率」ではありません。load average は 実行可能（runnable）状態または割り込み不可能（uninterruptible, D state）状態のタスク数 を、1/5/15分の指数移動平均で表したものです。

ここに2つの落とし穴があります。

1. コア数で正規化されていない。load average が 4.0 でも、4コアなら飽和ぎりぎり、16コアなら余裕です。load average ÷ コア数 で評価する必要があります。
2. CPU飽和とI/O待ちが混ざる。Linuxでは、ディスクI/O待ちで D state に入ったプロセスも load average に算入されます。そのため、CPUは暇でもストレージが詰まれば load average は跳ね上がります。「load が高い＝CPU不足」と即断すると誤診します。

vmstat 1 の出力では、先頭の r 列が「実行待ちのプロセス数（run queue 長）」、b 列が「割り込み不可能スリープ中のプロセス数」です。r がコア数を継続的に超えているなら、それはCPUが飽和し、実行待ちの列が伸びている直接の証拠です。load average のように平滑化されていないぶん、先行指標として鋭く反応します。

真のサチュレーション信号

利用率が100%に達する 前 に劣化を予告する、層ごとの代表的な飽和信号を整理します。

メモリのスワップ は特に重要な先行指標です。利用率（メモリ使用量）が物理容量に近づくと、カーネルはページを退避し始めます。スワップイン／アウトが恒常的に発生し出した瞬間が「性能の崖」の入り口です。ディスク速度はメモリより桁違いに遅いため、スワップが回り出すとレイテンシは段違いに悪化します。メモリ使用率が高いことより、スワップ活動が始まったことのほうが、はるかに鋭い警告 です。

TCP の accept backlog はネットワーク層の飽和信号です。サーバーが accept() で接続を引き取る速度より、新規接続（SYN-ACK完了済み）の到着が速いと、完了済みコネクションのキューが溢れます。Linuxでは nstat の TcpExtListenOverflows / TcpExtListenDrops の増加として観測でき、これはアプリケーションが受理処理を追い越されている——まさに飽和——を示します。利用率（CPU/メモリ）が無風でも、ここだけ溢れることは珍しくありません。バックプレッシャと過負荷の連鎖については/devops/congestion-collapse-backpressure/が詳しいです。

PSI:飽和を直接測るカーネル指標

Linux 4.20以降の PSI（Pressure Stall Information） は、飽和を間接推定ではなく直接測るために設計された指標です。/proc/pressure/cpu・memory・io を読むと、some（少なくとも1つのタスクが資源待ちで停止した時間割合）と full（全タスクが同時に待たされた時間割合）が得られます。

これが飽和指標として優れている点は、「資源を待たされて実際に進捗が止まった時間」を測っている ことです。利用率は「資源が動いていた割合」ですが、PSIは「仕事が止められていた割合」——需要側から見た不足量を直接定量化します。memory full が増えていれば、利用率の見た目によらず確実にメモリ飽和が起きています。

先行指標として監視する

飽和監視の価値は 先行性（leading indicator） にあります。利用率やエラー率は結果が出てから動く遅行指標ですが、待ち行列の伸びは、応答時間が悪化し切る前に立ち上がります。アラート設計でこれを使う際は、症状（ユーザー影響）ベースのページングと組み合わせるのが定石です（/devops/alerting-theory/）。

• 瞬間値・分位点で見る。平均利用率ではなく、キュー長そのものや PSI、run queue の高分位点を監視する。平均は飽和を平滑化で隠す。
• 資源層ごとに分離する。load average のような混合指標に頼らず、CPU・メモリ・I/O・ネットワークの飽和を別々に観測し、どの層が詰まっているか特定できるようにする。
• 崖の前で動く。スワップ開始・backlog 溢れ・キュー滞留の立ち上がりを閾値にすれば、利用率100%という遅い合図を待たずに、過負荷制御（/devops/adaptive-load-shedding/）を発動できる。

まとめ

• 利用率は飽和の手前で頭打ちになり劣化を予告しない。応答時間は 1/(1-ρ) で爆発するため、利用率が平坦に見える領域で待ち行列は伸びている。
• load average は CPU使用率ではなく、実行可能＋I/O待ちタスク数の指数移動平均。コア数で正規化し、平滑化前の run queue 長で補う。
• 真の先行指標は待ち行列の伸び——run queue 長・スワップ活動・TCP backlog 溢れ・PSI。利用率100%を待たず、崖の前で検知して手を打つ。