ハードウェア中級 #1 性能指標の読み方 — 遅いを数字に変える
ハードウェア基礎 で「遅い・高いの原因は CPU・メモリ・ストレージ・ネットワークの 4 つのリソースのどれか」というメンタルモデルをつかみました。中級シリーズはそのモデルを運用の場面に持ち込みます。サーバーが実際に遅くなったとき指標を読み、4 つのうちどこが詰まっているかを切り分け、ハードウェアレベルの処方を出す作業です。
シリーズは全 9 編です。指標の読み方 (1 編) から出発し、CPU (2 編)、メモリ (3 編)、NUMA (4 編)、ストレージ性能 (5 編) と RAID 運用 (6 編)、ストレージネットワーク (7 編)、GPU サーバー (8 編) を経て、最後の 9 編では遅くなったサーバーを最初から最後まで診断するウォークスルーで締めくくります。
第 1 編の主題はツールではなく解釈です。top の起動方法は RHEL 上級 #3 が扱います。この記事はその画面に出た数字が ハードウェアで何を意味しているのか を扱います。
リソースごとに 3 つを問う — 使用率・飽和・エラー #
4 つのリソースのどこを見ても、問いは同じ 3 つです。性能分析で USE (Utilization、Saturation、Errors) と呼ばれる枠組みです。
| 問い | 意味 | 例 |
|---|---|---|
| 使用率 (Utilization) | リソースが働いた時間の割合 | CPU 80%、ディスク busy 60% |
| 飽和 (Saturation) | リソースを待って列に並ぶ仕事の量 | 実行待ちキュー、ディスク I/O キュー |
| エラー (Errors) | リソースの動作失敗 | ディスク I/O エラー、パケットドロップ |
3 つのうち運用者がもっとも見落としがちなのが飽和です。使用率は「いま忙しいか」で、飽和は「いま列ができているか」です。ユーザーが体感する遅延を作るのは列、つまり飽和の側です。使用率 100% でも列がなければリソースを無駄なく使えている状態で、使用率 70% でも列が長ければすでにボトルネックです。瞬間的にリクエストが集中するバーストがあれば、平均使用率が低くても列はできます。
このシリーズ全体をこの枠組みで進めます。2 編の CPU も 5 編のディスクも、結局「使用率はいくつか、列はできているか、エラーはないか」の繰り返しです。
ロードアベレージ — CPU の列とディスクの列の合計 #
Linux でもっとも有名で、もっともよく誤解される指標がロードアベレージ (load average、実行中または実行・I/O を待つタスク数の 1・5・15 分平均) です。
$ uptime
14:02:11 up 41 days, 3:17, 1 user, load average: 8.42, 6.10, 4.55読み方の核心は 2 つです。
- コア数と比べて初めて意味が生まれます。ロード 8 は 8 コアのサーバーでは「ちょうどフル稼働」で、2 コアのサーバーでは「6 個のタスクが列に並んでいる」状態です。基礎 #2 のコアの概念がここで基準線になります。
- Linux のロードにはディスクを待つタスクも含まれます。CPU が暇なのにロードが跳ね上がるなら、犯人は CPU ではなくストレージである可能性が高いです。ロードアベレージは「CPU の指標」ではなく「CPU の列 + I/O の列」の合計指標です。
3 つの数字の傾きも情報です。1 分の値が 15 分の値より大きければ列は伸びている最中で、逆なら解消に向かっています。
CPU 使用率の内訳 — 同じ忙しさではない #
CPU 使用率はひとかたまりの数字ではなく内訳があります。どこに時間を使ったかによって処方がまったく変わります。
| 項目 | 意味 | 高いときのシグナル |
|---|---|---|
| us (user) | アプリケーションコードの実行 | 本当に計算が多い。コード最適化かコア増設 |
| sy (system) | カーネルコードの実行 | システムコールの多発、頻繁なコンテキストスイッチ |
| wa (iowait) | やることが I/O 待ちだけで遊んでいた時間 | ボトルネックは CPU ではなくストレージ |
| st (steal) | ハイパーバイザーが CPU をくれず動けなかった時間 | 仮想マシンの CPU 競合。2 編で詳しく |
特に wa は名前のせいで誤解が多いです。iowait は CPU が働いた時間ではなく、I/O 以外にやることがなくて遊んでいた時間 です。wa が 40% なら「CPU が忙しい」ではなく「CPU は暇なのにディスクが追いつかない」という意味なので、視線を 5 編のストレージに移す必要があります。
4 つのリソースの最初のチェックリスト #
指標をリソースごとにまとめると、遅くなったサーバーの前で投げる最初の質問リストになります。
| リソース | 使用率 | 飽和 | エラー |
|---|---|---|---|
| CPU | us+sy の割合 | ロード vs コア数、実行待ち | (まれ) MCE ログ |
| メモリ | 使用量 vs available | スワップ in/out の発生 | OOM キルの記録 |
| ストレージ | ディスク busy % | I/O キューの長さ、レイテンシ増加 | I/O エラー、リトライ |
| ネットワーク | 帯域幅の使用量 | 送受信キュー、再送 | パケットドロップ、エラーカウンタ |
各セルを埋めるコマンドは環境ごとに違いますが (vmstat、iostat、ss、クラウドなら CloudWatch のようなモニタリングコンソール)、セル自体はどこでも同じです。この表のセルを上から埋めていくことが 9 編のウォークスルーの骨組みになります。
よく出会う落とし穴 #
- 使用率だけ見て飽和を見ない — 「CPU 70% だから余裕がある」は列の存在を無視した結論です。平均 70% にバーストが重なれば列はすでにできています。使用率の隣に常に待ち行列の指標を並べます。
- ロードアベレージを CPU 需要としてだけ読む — Linux のロードには I/O 待ちが混ざっています。ロードが高ければ CPU とディスクの両方を疑う必要があります。
- 普段の値を知らない — ロード 6 が異常かどうかは、普段が 2 だったか 5 だったかにかかっています。正常時の指標を記録しておくことが診断の速度を決めます。
まとめ #
今回つかんだ絵です。
- どのリソースでも 使用率・飽和・エラー の 3 つを問います。体感の遅延を作るのはたいてい飽和 (列) です。
- ロードアベレージはコア数と比べて読み、Linux では I/O 待ちまで混ざった合計指標であることを覚えておきます。
- CPU 使用率は us・sy・wa・st の内訳に分けて読みます。wa が高ければ視線はストレージへ向かいます。
- リソースごとの 3 つの問いのチェックリストが診断の出発点で、普段の値の記録がそのチェックリストの基準線です。
次回 — CPU 深掘り #
次の記事「ハードウェア中級 #2 CPU 深掘り — ターボ・スロットリング・スチールタイム」では最初のリソースに入っていきます。クロックがスペック表の数字どおりに回らない理由 (ターボとスロットリング)、st が教えてくれる仮想化の影、そしてコンテキストスイッチのコストまで、基礎 #2 の概念の上に運用の層を積み上げます。