LinuxでSysstatをマスターする：sar・iostat・mpstatで断続的なパフォーマンス問題を診断する

Table of Contents

深夜2時、3時間前にサーバーが遅かった

午後11時に監視アラートが鳴り、レスポンスタイムが急上昇。ユーザーから苦情が来た。SSHでログインしたときには、すべて正常に見えた――CPUアイドルが90%、ロードアベレージも正常。インシデントは過ぎ去ったが、原因はわからないまま。

こんなときに頼りになるのがsysstatです。topやhtopと違い、sysstatは今この瞬間の状況を表示するだけではありません。CPU使用率、ディスクI/O、メモリ、ネットワークなどのパフォーマンスデータをバックグラウンドで継続的に収集し、履歴として保存し続けます。午後11時に問題が発生して、深夜2時に確認しても、当時の状況を正確に遡って確認できます。

4GB RAMの本番Ubuntu 22.04サーバーで断続的な速度低下に何度も悩まされてきました。sysstatを正しく設定してからは、ようやく原因を特定するための詳細なデータが手に入りました――特定の時間帯にディスクI/Oを酷使していたcronジョブが犯人でした。

背景と理由：Sysstatが実際に行うこと

Sysstatは、Linux向けのパフォーマンス監視ユーティリティ集です。最もよく使う3つのツールを紹介します：

sar（System Activity Reporter）――メインツール。過去のデータファイルからCPU・メモリ・I/O・ネットワークなどを報告します。
iostat――CPUとディスクI/Oの統計に特化。ボトルネックになっているストレージデバイスの特定に最適です。
mpstat――CPU別の統計。シングルスレッドプロセスでよく見られる「1コアが100%のまま他のコアが遊んでいる」状況の発見に役立ちます。

隠れた主役はsadc（System Activity Data Collector）です。デフォルトでは10分ごとにcronジョブとして動作し、バイナリデータファイルを/var/log/sysstat/に書き込み続けます。このファイルがタイムマシンの役割を果たし、過去28日間の任意の時間帯を照会できます。

診断の流れはシンプルです：アラートが鳴る → SSHでログイン → 正常に見える。そこでsarでインシデント発生時の時間帯を指定すれば、当時の実際の状況がわかります。推測は不要です。

インストール

Debian/Ubuntuの場合：

sudo apt update
sudo apt install sysstat -y

RHEL/CentOS/AlmaLinuxの場合：

sudo dnf install sysstat -y

注意点：Debian/Ubuntuの多くのディストリビューションでは、インストール後もデータ収集がデフォルトで無効になっています。有効化が必要です：

# Debian/Ubuntuの場合 — sysstatの設定ファイルを編集する
sudo nano /etc/default/sysstat

ENABLED="false"をENABLED="true"に変更して保存します。

# sysstatサービスを起動・有効化する
sudo systemctl enable sysstat
sudo systemctl start sysstat

# 動作確認
sudo systemctl status sysstat

RHELベースのシステムでは、インストール後にサービスが自動的に有効化されます。cronジョブが存在するか確認してみてください：

ls /etc/cron.d/sysstat
cat /etc/cron.d/sysstat

設定

収集間隔の調整

デフォルトの10分間隔は一般的な用途では問題ありません。負荷が急増する本番サーバーでは2分に短縮するのがおすすめです――インシデント発生時の解像度が大幅に上がり、オーバーヘッドはほとんどありません。

cronファイルを編集します：

sudo nano /etc/cron.d/sysstat

デフォルトのエントリを以下から：

# システムアクティビティ記録ツールを10分ごとに実行する
*/10 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

以下に変更します：

# 2分ごとに収集する
*/2 * * * * root command -v debian-sa1 > /dev/null && debian-sa1 1 1

データ保存期間の延長

デフォルトの保存期間は7日間です。本番システムでは28日間に設定することで1ヶ月分の履歴が残ります――週次パターンの発見や、すぐに調査できなかったインシデントの再確認に役立ちます。

sudo nano /etc/sysstat/sysstat

以下の箇所を見つけて更新します：

HISTORY=28

収集されるデータ

データは/var/log/sysstat/にsa01、sa12などの日次バイナリファイルとして保存されます（ファイル名の数字は日付）。一覧表示するには：

ls -lh /var/log/sysstat/

ストレージの消費量はわずかです。4GB RAMのUbuntuサーバーで2分間隔の場合、1日あたりのファイルサイズは2MB未満。1ヶ月分の履歴でも60MB以下――過去4週間のインシデントをいつでも調査できることを考えれば、非常に安いコストです。

確認と監視

sarでインシデントを再現する

よくあるシナリオ：昨晩何かが起きた。原因を知りたい。sarで時間範囲を指定してクエリを実行します：

# 今日の午後10時から深夜0時のCPU使用率
sar -u -s 22:00:00 -e 00:00:00

# 特定の日付を確認する（例：今月10日）
sar -u -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10

-uフラグはCPU使用率を表示します。注目すべき主要な列：

%user――ユーザー空間のCPU使用率
%system――カーネルのCPU使用率（値が高い場合はI/OやシステムコールのI/O問題を示唆）
%iowait――I/O待機時間（継続して20%を超えると要注意）
%idle――空きCPU容量

# メモリ使用率の履歴
sar -r -s 22:00:00 -e 00:00:00

# スワップ使用率（4GB RAMサーバーでは特に重要）
sar -S -s 22:00:00 -e 00:00:00

iostatでディスクI/Oを分析する

sarの%iowaitが高い場合、何かがディスクをブロックしています。iostatでどのデバイスでどの程度の問題が起きているかを確認します：

# リアルタイム：2秒ごとに更新、拡張統計を表示
iostat -x 2 5

# 特定のデバイスに絞る
iostat -x sda 2 5

iostat -xの出力で注目すべき列：

await――I/Oリクエストの平均待機時間（ms）。HDDで100ms超、SSDで20ms超は要調査。
%util――デバイスの使用率。100%近くなるとディスクが飽和状態。
r/sとw/s――1秒あたりの読み取りと書き込み回数。

過去のI/Oデータを確認するには、sarに戻ります：

# ディスクI/Oの履歴
sar -d -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10

mpstatでCPU別に分析する

CPU全体の使用率が40%でも安心はできません。シングルスレッドプロセスが1コアを100%に張り付けたまま、他のコアが遊んでいる――そんな状況でサーバーはのたうち回ります。mpstatはこれを見抜きます：

# 全CPUを表示、2秒ごとに更新
mpstat -P ALL 2 5

本番サーバーでこれを実行したところ、ピーク時にPHP-FPMのワーカーがCPU0を100%に張り付けたまま、CPU1・CPU2・CPU3が遊んでいることが判明しました。PHP-FPMのワーカー数とプロセスアフィニティを調整して解決。topだけでは絶対に気づけませんでした。

過去のCPU別データを確認するには：

# コア別の過去のCPUデータ
sar -P ALL -s 22:00:00 -e 00:00:00 -f /var/log/sysstat/sa10

実践的なインシデント調査ワークフロー

5つのコマンド。過去のパフォーマンス問題を調査するときに実際に実行する手順です：

# ステップ1：スパイクを見つける――1日全体のCPU概要
sar -u -f /var/log/sysstat/sa10 | grep -v "^$"

# ステップ2：スパイクが見えたら時間帯を絞り込む
sar -u -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10

# ステップ3：メモリを確認――RAMが枯渇してスワップが頻発していなかったか？
sar -r -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10

# ステップ4：ディスクI/Oを確認――大量書き込みが発生していなかったか？
sar -d -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10

# ステップ5：ネットワークを確認――トラフィックの急増はなかったか？
sar -n DEV -s 22:30:00 -e 23:30:00 -f /var/log/sysstat/sa10

クイックサマリーレポート

すべてを一度に確認したい場合は？sar -Aで1日分のフルレポート――CPU・メモリ・スワップ・I/O・ネットワーク――をスクロール可能な形式で出力できます：

# 特定の日のデータファイルのフルレポート
sar -A -f /var/log/sysstat/sa10 | less

1日の終わりのレビューや、インシデント発生時にオンラインでなかったチームメンバーへの引き継ぎに役立ちます。

データ収集について最後に一つ

インストール直後はまだ履歴データが存在しません――アーカイブが蓄積されるまで時間がかかります。すべてが正しく動作しているか確認するために、最初のデータ収集を手動でトリガーしましょう：

# 即時データ収集をトリガーする
sudo /usr/lib/sysstat/debian-sa1 1 1

# データが書き込まれているか確認する
ls -lh /var/log/sysstat/sa$(date +%d)

ファイルサイズが0より大きければ、sysstatが正常にデータを収集しています。

フラグなしでsarを実行すると当日のCPUデータが表示されます――次の深夜2時のインシデントが来る前の簡単な動作確認になります。