詳解 システム・パフォーマンス - 第2章：メソドロジ

診断の全体フロー

① 問題ステートメント（数値で定義）
    ↓
② 60秒チェックリスト（初動で全体を把握）
    ↓
③ USE法（リソース別に体系的に確認）
    ↓
④ ワークロード分析（誰が・何を・なぜ）
    ↓
⑤ ドリルダウン（perf / strace / bpftrace で深掘り）
    ↓
⑥ レイテンシ分析（どこで時間を使っているか）

---

USE Method（インフラ層の診断）

すべてのシステムリソースについて U・S・E の3指標 を確認する。

対象リソース × 確認コマンド

リソース	Utilization（使用率）	Saturation（飽和度）	Errors（エラー）
CPU	mpstat %usr+%sys	vmstat r列（runキュー）	dmesg
メモリ	free 使用率	vmstat si/so（スワッピング）	dmesg OOM
ディスク	iostat %util	iostat await（待ち時間）	dmesg, smartctl
ネットワーク	sar -n DEV（NIC使用率）	ss -s（接続数）	sar -n TCP（retrans）
ファイルシステム	df -h	iostat	dmesg

各指標の読み方

Utilization（使用率）

• 0〜100% で表現。70%以上 で要注意、100% で飽和目前
• CPUの場合：us + sy の合計
• ディスクの場合：iostat %util

Saturation（飽和度）

• キューに積まれた「こなせていない仕事」の量
• CPUの場合：vmstat r列（runキューのプロセス数 > CPUコア数 → 飽和）
• メモリの場合：vmstat si/so > 0 → スワッピング発生 = メモリ飽和

Errors（エラー）

• ハードウェアエラー・設定エラー
• dmesg | grep -i error
• dmesg | grep -i "out-of-memory"

---

60秒 Linux 診断チェックリスト

本番でパフォーマンス問題が報告されたときに最初に実行する10コマンド。

# 1. 負荷平均（1分/5分/15分）
uptime
# load averageがCPUコア数を超えていたら → CPUが詰まっている可能性
# 15分値が高くて1分値が低い → 過去に問題があった

# 2. カーネルエラー
dmesg | tail -20
dmesg | grep -i "out-of-memory"  # OOM killer 発動チェック
dmesg | grep -i error             # ハードウェアエラー

# 3. 仮想メモリ統計（1秒間隔）
vmstat 1 5
# r: runキュー > CPUコア数 → CPU不足
# b: ブロック中プロセス > 0 → I/O待ち
# swpd > 0 / si・so > 0 → スワッピング = メモリ不足
# us+sy: CPU使用率 / id: アイドル

# 4. コア別CPU使用率
mpstat -P ALL 1 3
# %iowait 高い → ディスクI/Oボトルネック
# %sys 高い → カーネルオーバーヘッド（syscall多い）
# %soft 高い → ソフト割り込み（NIC処理過多など）

# 5. プロセス別統計
pidstat 1 3
# CPU/メモリ/I/Oを時系列でプロセス単位に見る
# 急激に増えているプロセスが犯人候補

# 6. ディスクI/O詳細
iostat -xz 1 3
# %util > 80% → ディスク飽和
# await > 数十ms → I/Oレイテンシ問題（HDDなら許容範囲広め）
# svctm << await → キューに積まれている

# 7. メモリ使用状況
free -h
# available が少ない → OOMリスク
# available = free + buffers + cache（解放可能なメモリを含む）

# 8. NIC統計
sar -n DEV 1 3
# rxkB/s, txkB/s がNIC帯域に近づいていたら → NIC飽和

# 9. TCP統計
sar -n TCP,ETCP 1 3
# retrans/s 増加 → ネットワーク品質問題（パケットロス）
# active/s 急増 → 接続数が爆発

# 10. プロセス全体確認
top -b -n 1 | head -30
# Shift+M → メモリ順ソート
# Shift+P → CPU順ソート

---

各コマンドの出力の読み方

vmstat の列

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 5420000 380000 2100000    0    0     2    10  200  500  5  2 92  1  0

r=1: runキュー1個（正常）
b=0: ブロックなし（正常）
swpd=0: スワップ未使用（正常）
si=so=0: スワッピングなし（正常）
us=5, sy=2: CPU使用率7%（正常）
wa=1: iowait 1%（正常）

iostat -x の列

Device  rrqm/s wrqm/s r/s  w/s  rKB/s  wKB/s await %util
sda       0.00   5.00  0.0 50.0   0.0  200.0  2.50  25.0

await=2.5ms: リクエストの平均待ち時間（正常）
%util=25%: ディスク使用率25%（余裕あり）

---

RED Method（サービス層の監視）

USE法はインフラリソースの診断。サービス品質の監視には RED法 を使う。

指標	意味	計測方法の例
Rate	秒あたりのリクエスト数	アプリログ・Prometheus rate()
Errors	失敗リクエスト数（HTTP 5xx等）	アプリログ・エラー監視
Duration	リクエスト処理時間	p50/p95/p99 パーセンタイル

# Nginx ログからエラー率を確認
grep " 5[0-9][0-9] " /var/log/nginx/access.log | wc -l

# レスポンスタイムの分布（AWK で p95 を近似）
awk '{print $NF}' /var/log/nginx/access.log | sort -n | \
  awk 'BEGIN{c=0} {a[c++]=$1} END{print a[int(c*0.95)]}'

USE法との使い分け

インフラ層の問題（CPU/メモリ/ディスク/NIC） → USE法
サービスの品質問題（遅い・エラー多い）      → RED法
両方                                         → 併用

---

ワークロード分析

「誰が・何を・なぜ・どのように」リソースを使っているか を確認する。

# Who: CPU を最も使っているプロセス
ps aux | sort -k3 -rn | head -10

# Who: メモリを最も使っているプロセス
ps aux | sort -k4 -rn | head -10

# What: 何のシステムコールをしているか
strace -c -p <PID>         # syscall 集計（5秒後に Ctrl+C）
strace -o trace.txt -p <PID>  # 詳細ログ

# Why: なぜこの CPU 使用率なのか（フレームグラフで確認）
perf record -g -F 99 -p <PID> sleep 10
perf report

# How: どのパターンでリクエストが来ているか
sar -n TCP,ETCP 1 10
ss -tnp | wc -l   # 現在の接続数

---

レイテンシ分析（ドリルダウン）

遅延の原因を層ごとに分解する。

分解の順序

アプリケーション層のレイテンシ
  ↓ strace で確認
システムコール（open, read, write, connect）
  ↓ perf で確認
カーネル処理（VFS, TCP/IP stack, scheduler）
  ↓ bpftrace で確認
ハードウェア（ディスクレイテンシ, NIC遅延）

コマンド例

# アプリレベルの全体レイテンシ
time curl -w "%{time_total}s\n" http://localhost:8080/api/health

# syscall 別の実行時間内訳
strace -T -e trace=network,file -p <PID> 2>&1 | head -50
# -T: 各 syscall の実行時間を表示

# カーネル関数レベルのレイテンシ
perf record -g -F 99 -p <PID> sleep 10
perf report --stdio | head -50

# ディスク I/O のレイテンシ分布
sudo biolatency    # BCC tool（インストール要）
# histogram で p99 を確認

---

ベンチマーク・実験の原則

チューニング前後の効果測定に必要な基本原則。

原則	内容
コントロール変数	一度に変更するのは1箇所だけ
十分な測定回数	最低5回、できれば10回以上
ウォームアップ	JIT・キャッシュが安定してから計測開始
パーセンタイル重視	平均値ではなく p95/p99 で評価
外部要因を排除	計測中は他の負荷をかけない

# 繰り返し計測の例
for i in {1..5}; do
  time curl -s http://localhost:8080/api/benchmark > /dev/null
done