はじめに

性能試験で「いつから遅くなったのか」「負荷のピークはどこか」を探るには、時系列データの確認が欠かせません。
sarはCPU / メモリ / スワップ / ディスクI/O / ネットワークなどの統計情報を時系列で収集・表示できます。

💡 補足
時系列データは「時間ごとのスナップショット」を蓄積したもので、システムの変化や傾向をあとから追跡できます。

sarの基本コマンドと使い方

基本構文

sar [オプション] [間隔(秒)] [回数]

例）sar -u 1 10 → 1 秒ごとに 10 回 CPU 使用率を表示。

🗂 /var/log/sa/saXX 形式で日次ログが保存されており、-f オプションで指定可能です。例：
sar -u -f /var/log/sa/sa17 → 17日のCPU使用率を確認

各リソースの主要指標の見方

CPU指標（sar -u）

メモリ指標（sar -r）

スワップ指標（sar -S）

ディスクI/O指標（sar -b, sar -d）

ネットワーク指標（sar -n DEV）

sar出力の見方（代表的な例）

sar はオプションを変えるだけで CPU / メモリ / スワップ / ディスク I/O / ネットワーク を時系列で可視化できます。ここでは各リソースごとに “典型的な出力例” を示し、読み方と分析ポイント を整理します。

CPU 使用率（sar -u）

10:00:00 AM CPU %user %nice %system %iowait %steal %idle
10:10:00 AM all  20.00  0.00   10.00    5.00    0.00  65.00
10:20:00 AM all  35.00  0.00   15.00    8.00    0.00  42.00

• 読み方
  • %user + %system が高い → CPU計算量が増加
  • %iowaitが高い → ディスク or ネットワーク I/O待ち
  • %idleが低い → CPUに余裕がない状態

• 分析ポイント
  • %iowaitも同時に上昇していれば I/O がボトルネック
  • 仮想環境で %steal が10%以上なら、他VMとのCPUリソース競合が発生している可能性ある。 ホスト全体のCPU過負荷や、他VMの高負荷動作を疑う

メモリ使用量（sar -r）

10:00:00 AM kbmemfree kbmemused %memused kbbuffers kbcached kbactive
            1048576   2097152    66.7     128000   256000   512000
10:10:00 AM  512000   2621440    83.6      64000   128000   768000

• 読み方
  • kbmemfree減少 / %memused 上昇 → 空きメモリ減少
  • kbcached減少 → キャッシュを使い切り始めた兆候

• 分析ポイント
  • kbactiveが増えていれば 実プロセスがメモリを消費
  • 空き + キャッシュが枯渇するとスワッピングが発生しやすい

スワップ状況（sar -S）

10:00:00 AM kbswpfree kbswpused %swpused pswpin pswpout kbcommit %commit
            2048000       0      0.0      0      0     1048576   25.0
10:10:00 AM 1800000   248000    12.1     40     60     1258291   30.0

• 読み方
  • pswpin, pswpoutが発生 → スワップイン／アウト中
  • %commitが100%に近づく → 物理＋スワップ全体が逼迫
• 分析ポイント
  • pswpoutが連続増加 = メモリ不足でページが大量退避
  • kbcommitの伸びは予約メモリ（commit charge）の増加サイン

ディスク I/O（sar -b / sar -d）

10:00:00 AM tps rtps wtps bread/s bwrtn/s
             50   10  40   5120    20480
10:10:00 AM 120   20 100  12288    40960

• 読み方
  • tps（I/O要求数/秒）が急増 → ディスク負荷が上昇
  • bread/s / bwrtn/s → 読み書き量のトレンドを見る
• 分析ポイント
  • sar -u の %iowaitとセットでCPUがI/O待ちかどうかを確認
  • 曜日や時間帯でスパイクするなら バックアップ・バッチ処理を疑う

ネットワークトラフィック（sar -n DEV）

10:00:00 AM IFACE rxpck/s txpck/s rxkb/s txkb/s ifutil
           eth0    1250     960    820     640   25.0
10:10:00 AM eth0    2500    2200   1640   1280   49.5

• 読み方
  • rxkb/s, txkb/s の増減で受信／送信量を確認
  • ifutil が 70% を超え続ける → 帯域の逼迫
• 分析ポイント
  • トラフィック急増と同時にCPUの %softirq や 受信パケット数（rxpck/s）が急増していれば、ネットワーク割り込みがボトルネック
  • 複数インターフェースがある場合はボンド設定や負荷分散を検討

📝 総合Tips

• 異常値が出た時刻を起点に、sar 各オプションのログを横串で確認すると効果的。
• CPU高負荷＋bread/s増加→「I/O原因のCPU飽和」など、原因と結果が結び付けやすい。

実践例：ログから負荷ピークを特定する

性能試験中に Web サーバーの応答が低下。
sar -u -f /var/log/sa/sa17 で確認した抜粋は次のとおりです。

03:00:00 PM   CPU   %user  %system  %iowait  %idle
03:10:00 PM   all    15.0      8.0      2.0   75.0
03:20:00 PM   all    40.0     15.0      5.0   40.0

分析ポイント

1. 15:10 → 15:20 で %user 15% → 40%、%idle 75% → 40%：
   → 15:20 前後に CPU 負荷が急増
2. %iowait も微増しており、I/O を伴う処理が重なった可能性

対処の方向

• 15:20 付近の アクセスログやジョブ投入 を調査
• 必要に応じ 負荷分散 や キャッシュ設定の強化 を検討

💡 性能試験Tips
ピーク時刻が分かれば「そのタイミングに何が起きたか」をピンポイントで追えるため、原因究明が大幅に楽になります。

まとめ

sarを使えば、CPU・メモリ・スワップ・ディスク・ネットワークといった各種リソースの使用状況を時系列で追跡できます。

性能試験や障害調査では、次のポイントを意識してログを確認しましょう。

• ピーク時間帯を特定し、その前後でリソース使用率（例: %user, %iowait, %memused, pswpout, tps など）がどう変化したかを見る
• 異常値が出た時間に、同時に起きたジョブ実行・アクセス集中・バッチ処理などがないかも併せて確認
• %idle や ディスクI/O量 (bread/s, bwrtn/s)、ネットワーク帯域 (rxkb/s, txkb/s) を組み合わせてボトルネックを特定する

sarは単体でも便利ですが、他のコマンド（vmstat, mpstat, jstatなど）と組み合わせることで、より多角的な分析が可能になります。

参考資料

• Linux man page: sar
• Sysstat Official Site