RHEL 上級 #3 パフォーマンス分析 — sar、top/htop、iostat、vmstat、perf

#2 カーネルチューニング でワークロードに合わせて調整するツールを見ました。この記事はその逆方向です。マシンがすでに動いているのに遅くなったとき、どこから見るかを定めます。top、vmstat、iostat、sar、perf の 5 つのツールをどんなシグナルで選ぶか、そして USE (Utilization · Saturation · Errors) というシンプルなチェックリストで束ねて 1 サイクルで扱います。

RHEL 上級 シリーズでこの記事の位置:

• #1 ブートプロセス — GRUB2、dracut、レスキューモード
• #2 カーネルチューニング — sysctl、tuned、kdump
• #3 パフォーマンス分析 — sar、top/htop、iostat、vmstat、perf ← この記事
• #4 SELinux 上級 — ポリシー作成、audit2allow
• #5 セキュリティ強化 — auditd、OpenSCAP、FIPS
• #6 Subscription / Satellite / Insights
• #7 Cockpit による GUI 管理と Web Console

4 つのリソースと USE チェックリスト #

パフォーマンス問題は結局 4 つのリソースのどこかで漏れています。

それぞれに対して同じ 3 シグナルを見ます — Brendan Gregg の USE 方法論。

• Utilization — リソースがどれだけ使われているか (使用率 %)
• Saturation — リソースが処理しきれず、キューに溜まっているか
• Errors — エラーが発生しているか

CPU が忙しく見えても (U 高) キューに溜まらず (S 低) エラーもなければ (E 0) 健全です。逆に CPU 使用率 50% でも run queue が 30 なら、使用率は普通に見えても saturation で赤信号が出た状態です。常に U/S/E の 3 つを一緒に見ると診断が正確になります。

最初の視野 — top / htop #

最も速く手に取れるツールです。マシンに入った直後にまず開くのが標準手順です。

$ top
top - 14:23:15 up 12 days,  4:11,  2 users,  load average: 1.52, 0.98, 0.65
Tasks: 312 total,   2 running, 310 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.3 us,  2.1 sy,  0.0 ni, 88.5 id,  0.7 wa,  0.3 hi,  0.1 si,  0.0 st
MiB Mem :  15891.2 total,   3421.5 free,   8123.4 used,   4346.3 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   7234.8 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 1234 postgres  20   0 1234567  98765  43210 R  45.2   0.6   3:12.45 postgres
 ...

1 行目 — load average #

load average: 1.52, 0.98, 0.65 の 3 つの数字は 過去 1 分 / 5 分 / 15 分の平均で実行可能状態だったプロセス数 です。

• CPU コア数 (例: 4) と比較 — 4 を超えると CPU が足りないシグナル
• 1/5/15 のトレンド — 1 分 > 15 分 なら負荷が上昇中、逆なら鎮静中
• Linux の load average は R 状態 + D 状態 (uninterruptible sleep、通常はディスク I/O 待ち) の両方を含みます。だからディスクが遅いと CPU が暇でも load が跳ね上がります。

CPU 行 — %Cpu(s) #

wa が高ければディスク/ネットワーク I/O のボトルネック、st が高ければ (クラウドインスタンスで) ノイジーネイバー影響を疑います。

htop — より読みやすい top #

$ sudo dnf install -y htop
$ htop

• コア別使用率の棒グラフ
• プロセスツリー表示 (F5)
• 検索 (F3)、フィルタ (F4)、kill (F9)、nice 変更 (F7/F8)
• マウスクリックでソート

運用では top が常にあると想定すべきですが (デフォルトインストール)、最初に手に取るインタラクティブツールとしては htop がはるかに速いです。

よく使う top ショートカット #

vmstat — CPU・メモリ・IO を 1 画面で #

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 421888  35420 1234560    0    0     8    23  150  280  3  1 95  1  0
 0  0      0 421872  35420 1234560    0    0     0     0  120  240  1  0 99  0  0
 2  1      0 421860  35420 1234560    0    0     0   512  185  320  8  2 88  2  0

何を見るか #

• r > CPU コア数 — CPU saturation。並んで待っているプロセスがある
• si/so > 0 — ページがスワップを行き来しています。メモリ saturation
• wa が高くて b > 0 — ディスク I/O ボトルネック
• cs が異常に高い — コンテキストスイッチ暴走 (スレッド過多、ロック競合など)

vmstat 1 の 1 行で 4 つのリソースの状態を同時に見られます — 診断の 2 枚目のカードです。

iostat — ディスクを詳しく #

sysstat パッケージに含まれます。

$ sudo dnf install -y sysstat
$ iostat -xz 1
Linux 5.14.0-... (host)   04/28/2026   _x86_64_   (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.32    0.00    1.84    2.41    0.00   90.43

Device            r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm  r_await  w_await aqu-sz  rareq-sz  wareq-sz  svctm  %util
nvme0n1         12.34   45.67    234.56    812.34     0.00     2.11   0.00   4.42     0.32     1.45   0.07     19.01     17.79   0.21   1.23
nvme0n1p1        0.00    0.01      0.02      0.05     0.00     0.00   0.00   0.00     0.10     0.50   0.00      8.00      8.00   0.05   0.00

-x 拡張統計、-z アクティビティが無いデバイスを隠す、1 秒間隔。

何を見るか #

• %util が 100% 近く + aqu-sz が大きい — ディスク飽和状態。SSD なら IOPS 限界付近の可能性
• await が異常に大きい (HDD: 20ms+、SSD: 5ms+) — 応答時間問題
• rkB/s + wkB/s がディスクスペックに近い — 帯域 saturation

%util だけ見ると誤解する場合があります。最新 NVMe は並列処理が可能で、%util 100% が直ちに saturation を意味しません。aqu-sz と await を併せて見ると正確です。

CPU と一緒に見る #

$ iostat -xz 1

iostat は最初の段落に CPU 平均まで表示します。CPU %iowait が高くてディスク %util も高ければディスクボトルネックが明確になる、という具合。

sar — 時間の流れ #

top/vmstat/iostat は今この瞬間を見ます。昨夜 3 時に何が起きたかは捉えられません。その役割を担うのが sar です。sysstat パッケージがバックグラウンドで 10 分ごと (デフォルト) にシステム統計を収集して /var/log/sa/ に蓄積します。

$ sudo systemctl enable --now sysstat
$ sudo systemctl status sysstat-collect.timer

時間単位の照会 #

$ sar -u
Linux 5.14.0-...   04/28/2026

00:00:01 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
00:10:01 AM     all      2.34      0.00      0.81      0.12      0.00     96.73
00:20:01 AM     all      3.21      0.00      0.92      0.14      0.00     95.73
...

$ sar -u -f /var/log/sa/sa27   # 27 日分

リソース別オプション #

時刻指定と平均行 #

$ sar -u -s 09:00:00 -e 11:00:00

# 平均のみ
$ sar -u -A | grep Average

パフォーマンス事故の事後解析の核心ツールです。事故の瞬間に張り付いていたわけではなく、後から入って再構成する場面。top では取れない時間帯の足跡を取れます。

sar データ保持期間 #

デフォルトは 28 日。/etc/sysconfig/sysstat の HISTORY= で延長します。

$ sudo sed -i 's/^HISTORY=.*/HISTORY=180/' /etc/sysconfig/sysstat

長期トレンド分析が必要な運用マシンは 90 ~ 180 日に延ばすのが標準です。

perf — CPU ホットスポット #

CPU が忙しいがどの関数が時間を食っているか知りたいときに使うのが perf です。カーネル関数まで含むコールスタック単位のプロファイラです。

$ sudo dnf install -y perf

30 秒間のシステム全体プロファイリング #

$ sudo perf record -F 99 -ag -- sleep 30
$ sudo perf report

特定 PID #

$ sudo perf record -F 99 -p 1234 -g -- sleep 30
$ sudo perf report

結果を見る #

perf report はテキスト UI。関数別の CPU 時間割合をコールスタックと合わせて表示します。

+   45.32%  postgres   postgres            [.] hash_search_with_hash_value
+   12.45%  postgres   postgres            [.] heap_hot_search_buffer
+    5.21%  postgres   libc-2.34.so        [.] __memcpy_avx_unaligned_erms
...

Flame Graph — 可視化 #

perf report のテキストは深いコールスタックを見にくい場面があります。Brendan Gregg の FlameGraph ツール で SVG に変換:

$ sudo perf record -F 99 -ag -- sleep 30
$ sudo perf script > out.perf
$ ./FlameGraph/stackcollapse-perf.pl out.perf > out.folded
$ ./FlameGraph/flamegraph.pl out.folded > flame.svg

ブラウザで flame.svg を開くと、コールスタックの幅がそのまま時間割合になります。どこが熱いかが一目で見えます。

束ねた 1 サイクル #

問題が来たときにどの順番でツールを使うか、1 サイクルで整理します。

1. top / htop          ← 最初の視野。load avg、CPU/MEM 大局
        │
2. vmstat 1            ← r、b、si/so、wa で CPU・MEM・IO を 1 画面
        │
3. リソースが見えたら — そのリソース専用ツールで深く
        │
   ├─ CPU 疑い  → perf record / report
   ├─ MEM 疑い  → free -h、/proc/meminfo、smem
   ├─ Disk 疑い → iostat -xz 1、biotop、iotop
   └─ Net 疑い  → ss -s、sar -n DEV/EDEV、iftop
        │
4. 時間の流れが必要 → sar -u/-r/-d/-n DEV (-f /var/log/sa/sa..)

よくある落とし穴 #

• load average だけ見て CPU 負荷と断定 — Linux load は D 状態を含みます。ディスクが遅いと CPU が暇でも跳ね上がります。常に vmstat の r と b を併せて。
• %util だけでディスク saturation を判定 — NVMe は並列処理。aqu-sz と await を併せて見ると正確。
• %CPU 合計が 100% を超えるのは異常? — 正常です。top のデフォルトはコア合算表示で、4 コアなら最大 400%。1 キーでコア別に展開するとコア当たりが見えます。
• sar 有効化漏れ — RHEL 9 は自動ですが、一部 minimal インストールでは抜けている場合があります。事故後に有効化してもその時点のデータは取れません。運用マシンは事前に有効化を。
• perf record を本番トラフィックに長時間 — サンプリング自体が若干のオーバーヘッド。本番インスタンスでは 30 秒 ~ 1 分単位で区切って実行。
• top のメモリ used を単純に合算 — buff/cache が used に含まれる表記。実際の利用可能は available で見るべき。free -h の available 列が信頼できる値です。

覚えておくコマンド #

まとめ #

• USE チェックリスト — Utilization · Saturation · Errors。CPU/MEM/Disk/Network の 4 リソースに対して 3 つを併せて見る。
• 最初のカードは top/htop — load average と大局。次に vmstat 1 で 4 リソースの状態を 1 画面で。
• リソースが絞れたら専用ツール — Disk は iostat -xz 1、CPU ホットスポットは perf record、メモリは free -h + smem。
• 時間の流れは sar — 事故後に入って見る場面。保持期間を 90 ~ 180 日に延ばすと長期トレンド分析に有用。
• シグナルを混同しないこと — load avg は D を含み、%util は NVMe で saturation 指標として不足、top のメモリ used は buff/cache を含む。

次回はセキュリティに再度深く入ります。中級 #1 SELinux 入門 で見た標準ツールの先 — ポリシーを直接書き、audit2allow でモジュールを作って永続適用する 流れを扱います。