LinuxのCPU高負荷・load averageを切り分ける手順

LinuxでCPU高負荷やload average上昇が疑われるときは、load、CPU使用状況、実行待ち、I/O待ちを同じ時刻帯で確認します。単一の値だけで原因を決めず、読み取り中心の観測結果をそろえて次の調査対象を絞ります。

原因確認と復旧操作を明確に分け、表示結果、観測時刻、タイムゾーンを記録してください。commandのoptionや表示は環境ごとに異なるため、導入されている版のman pageを優先します。

load averageとCPU使用率は同じではない

Linuxのload averageはCPU利用率そのものではありません。実行中またはCPUを待つrunnableなprocessに加え、I/Oなどを待つ割り込み不能状態のprocessも関係します。そのため、loadが高くてもCPU使用率だけが原因とは限らず、CPUが空いて見える場合もあります。

loadはCPU数で正規化されません。CPU数と並べると状況を考える材料になりますが、CPU数との比だけで正常・異常を固定判定せず、処理内容、平常時、監視値、後続の観測を組み合わせます。

1. 稼働時間と1分・5分・15分のloadを確認する

uptime

現在時刻、boot後の稼働時間、直近1分・5分・15分のload averageを確認します。短い期間だけが上がったのか、長い期間にも広がっているのかを記録し、監視の時系列と照合します。

2. online CPU数を確認する

getconf _NPROCESSORS_ONLN

現在の実行環境が報告するonline processor数を確認し、loadを読む際の文脈にします。getconf の対応変数や見えるCPU範囲は実装・実行環境によって異なるため、値を絶対的なしきい値にせず、環境の構成資料や監視設定とも照合します。

3. /proc/loadavgの元データを確認する

cat /proc/loadavg

先頭3項目は1分・5分・15分のload averageです。続くrunnable/totalは、現在runnableなtask（process/thread）数とsystem内のtask総数を示します。threadも含むため、process件数と単純に同一視しません。/proc/loadavg の値だけではCPU待ちとI/O待ちを分離できないため、次のCPU snapshotとvmstat を続けて確認します。

4. topを非対話の1回snapshotで確認する

top -b -n 1

batch modeで1 iterationだけ表示し、load、task状態、CPUのus・sy・id・wa、上位processを同じ出力で確認します。この結果も一時点のsnapshotです。表示順や列は設定・versionで変わるため、同じ条件での再観測や監視値と比較します。

5. process別の%CPUを確認する

ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu

%CPUが高い順にprocessを並べます。procps-ngのpsが示す%CPUは、processが使ったCPU時間をそのprocessの稼働時間で割った稼働期間全体の平均であり、瞬間値ではありません。短時間に変化したprocessを一度の順位だけで除外せず、topや時系列の観測と照合します。

cmdにはargument、path、credentialなどの機密情報が含まれる場合があります。出力を共有する前に内容を確認し、元の記録を保持したうえで共有用コピーをマスクしてください。

6. run queue・blocked process・CPU・I/O waitを一定間隔で確認する

vmstat 1 5

vmstat 1 5 は1秒間隔で合計5回reportを表示します。最初のreportはboot以降の平均で、追加のreportが各1秒のsampling期間を示します。r は実行中または実行待ちのprocess数、b はI/O完了を待つblocked process数です。CPU欄ではus・sy・id・waを同じsamplingで比較します。

waはI/O完了待ちに費やしたCPU時間の割合ですが、単一の値だけでstorage障害とは断定できません。b、block I/O、loadの推移、アプリケーションの応答、別の監視指標と時間を合わせて確認します。

CPU-boundとI/O waitを区別する考え方

CPU側の競合が疑われる

loadとrが増え、usやsyの上昇と、top・psの上位processが同じ時刻帯で対応するかを確認します。どれか一つだけで原因processを決めません。

I/O wait側が疑われる

load上昇時にbやwa、block I/O、応答遅延が同じ時刻帯で変化したかを確認します。loadが高いことだけをCPU飽和と同一視しません。

一時点だけで原因を断定しない

snapshotは取得した瞬間の状態です。各結果に観測時刻とタイムゾーンを添え、同じ条件の複数時点、監視グラフ、処理量、直近変更の時刻と比較します。観測した事実、原因候補、未確認事項を分けて引き継ぎます。

原因確認と復旧操作を分離する

この手順はload、CPU、実行待ち、I/O待ちを観測して原因候補を絞るところまでです。processの実行条件やserviceの状態を変える操作は、影響範囲、組織の承認手順、復旧計画を確認し、権限を持つ管理者が別途判断します。

コマンド仕様の参照先

optionや表示内容は導入環境のman pageを優先し、以下のupstream一次情報も参照してください。