サーバーが深夜に突然「フリーズ」したとき
午前2時、電話が鳴り止みません。監視システムがアラートを発しています。Webサーバーのレスポンスが10秒以上遅延しているとのこと。あなたは飛び起き、SSHでログインして top コマンドを打ちます。皮肉なことに、その時のCPU使用率は5%前後で、すべてが正常に見えます。SysAdminにとって最もフラストレーションが溜まるのは、システムに問題が発生したことは分かっているのに、犯人を突き止める証拠が何もないときです。
top や htop のようなコマンドは、リアルタイムの状態を確認するには非常に便利です。しかし、30分前に何が起こったかについては、これらは全くの「盲目」です。過去を振り返るには、システムログを記録できるツールセットが必要です。そこで sysstat が救世主となります。
長年大規模なクラスターを運用してきた経験から、私は sysstat を飛行機の「ブラックボックス」のようなものだと考えています。これはシステムのあらゆる健康指標を密かに記録し続けます。トラブルが発生した際、推測に頼るのではなく、単にデータを抽出して「事後分析」を行えばよいのです。
なぜデフォルトのツールだけでは不十分なのか？
top や free -m の問題点は、リアルタイムのデータしか提供しないことです。実際、パフォーマンスの問題は一瞬発生して消え去ることがよくあります。
例えば、バックアッププロセスが、ちょうど5分間だけディスクI/Oを詰まらせたと想像してください。その時間帯に直接コマンドを打っていなければ、手がかりを逃してしまいます。sysstat は定期的に（通常10分ごと）データを収集し、ログファイルに保存することで、いつでもクエリを実行できるようにし、この問題を解決します。
sysstatを30秒でインストールする
ほとんどの Linux ディストリビューションでは、リポジトリに sysstat が用意されています。インストールは非常に簡単です。
Ubuntu/Debian の場合：
sudo apt update && sudo apt install sysstat -y
sudo systemctl enable --now sysstatCentOS/RHEL/AlmaLinux の場合：
sudo yum install sysstat -y
sudo systemctl enable --now sysstat重要な注意点： Ubuntu の場合は特に、/etc/default/sysstat ファイルを修正する必要があります。sar データコレクターを有効にするために、ENABLED="false" を ENABLED="true" に変更してください。
1. mpstat：CPUコアごとの詳細分析
top が全体像を示すのに対し、mpstat (Multiprocessor Statistics) は各CPUコアのパフォーマンスを個別に分析するのに役立ちます。このコマンドは、局所的な過負荷を検出するのに非常に有効です。
mpstat -P ALL 2 5このパラメータは2秒ごとに更新し、5回繰り返します。以下の項目に注目してください：
- %iowait： この数値が 10% を超えている場合、CPUはディスクからのデータ待ちで「手持ち無沙汰」な状態になっています。これは最も顕著なI/Oボトルネックの兆候です。
- %usr： ユーザーアプリケーションの処理に使用されたCPUの割合です。
- %idle： %idle が低い（5%未満）場合、サーバーは計算処理で文字通り限界に達しています。
2. iostat：ディスクのボトルネックを見つける
以前、CPU使用率はわずか10%なのに、データベースサーバーがひどくラグるケースに遭遇しました。iostat を実行したところ、真実が判明しました。デバッグログがオフになっていなかったため、ディスクが書き込み（write）過負荷に陥っていたのです。
iostat -xz 1 10以下の2つの「黄金」の指標に集中してください：
- %util： この数値が 80-100% に達している場合、ディスクはフル稼働状態にあります。
- await： I/Oリクエストの平均処理時間です。SSDの場合、
awaitは 5ms 未満であるべきです。これが 20-50ms に跳ね上がると、ユーザーは明らかな遅延を感じ始めます。
3. vmstat：システムリソースの全体像
vmstat (Virtual Memory Statistics) は、私が初めて触るサーバーにログインしたときに必ず最初に打つコマンドです。プロセス、メモリ、スワップ、CPUについて簡潔にまとめてくれます。
vmstat 1 5危険な兆候は si (swap in) と so (swap out) の列にあります。これらの数値が継続的に0より大きい場合、メモリ（RAM）が枯渇していることを意味します。システムはディスクを一時メモリとして使用しています。ディスクの速度はメモリに遠く及ばないため、サーバーの動作は非常に重くなります。
4. sar：万能なシステム日記
これは sysstat ツールセットの中で最も価値のあるツールです。sar (System Activity Reporter) を使用すると、時間を遡って何が起こったかを確認できます。
今日の午前10時のCPUの状態を確認するには：
sar -u -s 10:00:00 -e 10:30:00または、一昨日（例えば19日）のネットワークトラフィックを確認するには：
sar -n DEV -f /var/log/sysstat/sa19覚えておくべき強力なフラグ：
-u：CPUを確認する。-r：メモリを確認する。-n DEV：ネットワークトラフィックを確認する。-q：Load Averageの履歴を確認する。
根本原因を特定するための4ステップ
サーバーの動作が重いと感じたとき、私は通常このチェックリストに従います：
- vmstat 1： 全体を確認。
r(runnable) 列が高い場合はCPUがビジー。b(blocked) 列が高い場合はI/Oが詰まっている。 - mpstat -P ALL 1： シングルスレッドのアプリケーションによって特定のCPUコアが酷使されていないか確認。
- iostat -xz 1： どのディスクパーティションがハングしているか、
awaitがどのくらいかを確認。 - sar： すでにトラブルが収まっている場合は、その時間帯の履歴を遡って上記の各指標を照合。
実際の例：8コアのサーバーで Load Average が 40 まで急上昇しました。iostat を使うと %iowait が 50% に達しているのが見えました。次に sar -n DEV で確認するとネットワークトラフィックは正常でした。最終的に、システムの updatedb スクリプトがディスク全体をスキャンしていることが判明しました。実行スケジュールを午前3時に変更するだけで解決しました。
結び
sysstat を使いこなすスキルを身につければ、受動的な対応から能動的な対応へと転換できます。遅いからとりあえず再起動するのではなく、なぜ遅いのかを正確に把握できるようになります。サーバーがダウンするのを待たずに、今すぐインストールして、sar によるデータの蓄積を始めましょう。
もし数値に異常が見られたら、下のコメント欄で教えてください。一緒に原因を解き明かしましょう。サーバーの最適化が成功することを願っています！
