1. はじめに
性能試験で応答が重くなったとき、原因を正しく見立てるには数字の読み方が大切です。この記事は、CPUが主な要因だったケースを例に、どの指標をどの順番で見ると結論にたどり着けるかをまとめたものです。
2. この章で使う用語
- run queue（ランキュー） … 実行待ちの行列。コア数よりrun queueが多いほどシステムに多くのジョブが発生している。
- 割り込み … 進行中の処理を中断して別の処理に応答すること。増えるほど切り替え負担が増える。
- コンテキストスイッチ … 実行中のタスクを入れ替えること。頻発すると実処理に使える時間が減る。
- iowait … CPUがI/Oの完了待ちで止まっている割合。
例：コア数16で run queue が80なら「待ち5倍」。この領域では並列を増やすほど遅くなることが多い。
3. ケース概要
CPUが主因のとき、典型的には次のように見えます（数値は一般的な目安）。
- アプリ側
・CPU利用率が継続して95％超
・run queueが物理コアの2〜5倍で張り付き
・割り込み／コンテキストスイッチが平常時の数倍
・メモリに余裕があり、スワップは0
・GCの時間は小さい（おおむね5％未満）、Full GCなし〜少ない - DB側
・CPUが90％超で高止まり
・run queueがコア数超えで増加
・iowaitは低い（おおむね2％未満）
・メモリに余裕
→ まとめ：CPUの前に処理が並び続けている。一方で、ディスク待ちやメモリ不足、GC停止の影響は小さい。
図：CPU使用率の推移（例）
4. 見方の手順
- CPUが高い状態が続いているか
単発の山ではなく、高止まりが継続しているかを確認する。 - run queueがコア数を大きく上回っていないか
コア数＜run queue が長時間続けば、捌き切れていない合図。 - 割り込み／コンテキストスイッチが増えていないか
切り替えが平常の2〜3倍に増えると、実処理時間が削られる。 - I/Oとメモリに余裕があるか
iowaitが低く、空きメモリがありスワップ0なら、CPU以外が原因の可能性は低い。 - GCの負荷が小さいか
GC時間が短く、Full GCが無ければ、停止時間が主因ではないと切り分けられる。 - アプリとDBの動きが連動していないか
アプリの並列増に伴い、DBのセッションも増え、両方のCPUが高止まりしていないかを見る。
5. 観測チェック項目
- [ ] CPU利用率が継続して95％以上
- [ ] run queueがコア数の2倍超で続いている
- [ ] 割り込み／コンテキストスイッチが平常の数倍に増えている
- [ ] iowaitが低い、スワップは0
- [ ] GC時間が小さい（5％未満）、Full GCなし
- [ ] アプリの並列増とDBセッション増が同時に起きている
6. まとめ
CPUの詰まりを見抜くコツは次のとおりです。
- 全体像：CPUは高止まり、run queue はコア数を大きく上回る。一方で iowait は低く、メモリと GC に余裕がある。
- 読み取り：主因は CPU の計算リソース不足。I/O やメモリ不足、GC 停止は主要因ではない。
- 確認の流れ：CPU の継続高止まり → run queue 超過 → iowait 低位・スワップ 0 → GC 時間 小 → アプリと DB の連動。
- 次の一歩：どの処理が CPU を使い切っているかを測定で特定する。
コメント