2026年8月7日

Linuxのsarコマンドでシステム統計を確認する方法｜CPU・メモリ・I/Oの履歴を読む

バックアップ・監視

sar は、CPU・メモリ・ディスク・ネットワークの使用状況を一定間隔で記録し、後から時刻を指定して振り返れるコマンドです。「深夜にサイトが重くなったが、朝には直っていた」というとき、top や vmstat では過去の状態を見られませんが、sar なら当時の数字を確認できます。この記事では、sysstat の導入と記録の有効化、目的別のオプション、WordPress サーバーで遅延が起きたときの調べ方までを説明します。

sar と sysstat の関係

sar は sysstat というパッケージに含まれるコマンドです。sysstat には次の2つの役割があります。

記録：sa1 / sa2 という補助プログラムが、cron や systemd タイマーから定期的に呼ばれ、統計をバイナリファイルに保存する
表示：sar がそのファイルを読んで表示する。今この瞬間の値を数秒間隔で取ることもできる

つまり、パッケージを入れただけでは過去のデータは残りません。記録を有効にした時点から履歴がたまり始めます。障害が起きてから導入しても、その障害の時間帯は見られないので、本番サーバーには平常時から入れておくのが基本です。

手順1：sysstat を導入して記録を有効にする

Debian / Ubuntu 系の例です。

sudo apt install sysstat
# ディストリビューションによっては /etc/default/sysstat の ENABLED を "true" にする必要がある
sudo sed -i 's/^ENABLED="false"/ENABLED="true"/' /etc/default/sysstat
sudo systemctl enable --now sysstat

RHEL / AlmaLinux / Rocky Linux 系の例です。

sudo dnf install sysstat
sudo systemctl enable --now sysstat

有効化の方法は、ディストリビューションと sysstat のバージョンで異なります。最近の環境では systemd のタイマー（sysstat-collect.timer など）で収集する構成が多く、systemctl list-timers | grep sysstat で動いているかを確認できます（2026年10月現在）。

記録ファイルの置き場所も系統で違います。

Debian / Ubuntu 系：/var/log/sysstat/
RHEL 系：/var/log/sa/

ファイル名は日付を表す saDD（DD は日）が基本ですが、設定によっては年月日を含む名前になります。保存日数は sysstat の設定ファイル（Debian 系は /etc/sysstat/sysstat、RHEL 系は /etc/sysconfig/sysstat）の HISTORY で決まります。ディスク容量と相談して、少なくとも障害の振り返りに必要な日数を残してください。

収集間隔は既定で10分のことが多いです。10分平均では数十秒のスパイクが埋もれるため、短くしたい場合はタイマーや cron の設定を変更します。変更はパッケージ更新で上書きされないよう、systemd なら systemctl edit によるドロップインで行うのが安全です。

手順2：基本の使い方

# 今日の記録（CPU）を表示
sar

# 今この瞬間の値を1秒間隔で5回取る
sar -u 1 5

# 15日のファイルから、10時〜11時だけを表示（Debian/Ubuntu系のパス）
sar -u -f /var/log/sysstat/sa15 -s 10:00:00 -e 11:00:00

# 時刻を24時間表記にしたいとき
LC_ALL=C sar -u

ロケールによっては時刻が「午前/午後」の12時間表記になり、ログとの照合がしにくくなります。LC_ALL=C を付けると24時間表記で出せます。

手順3：目的別に見るオプション

CPU：sar -u / sar -P ALL

sar -u の主な列は %user（アプリケーション）、%system（カーネル）、%iowait（I/O待ち）、%steal（仮想化基盤に奪われた時間）、%idle（空き）です。

%user が高い：PHP や MySQL の処理そのものが重い
%iowait が高い：CPU は空いているのにディスク待ちで進まない
%steal が高い：VPS やクラウドで、同じ物理ホストの他の利用者の影響を受けている可能性がある。自分のサーバー内では解決できず、プラン変更や事業者への相談が必要になる

sar -P ALL でコアごとの値が出ます。全体平均は低いのに1コアだけ使用率が上限に張り付いている場合、シングルスレッドの処理が詰まっています。

負荷と待ち行列：sar -q

runq-sz（実行待ちのプロセス数）、ldavg-1 / ldavg-5 / ldavg-15（ロードアベレージ）、blocked（I/O待ちで止まっているプロセス数）を表示します。runq-sz がCPUコア数を長く上回っていればCPU不足、blocked が多ければI/O待ちが疑われます。

メモリ：sar -r / sar -S / sar -W / sar -B

sar -r の %memused は、ページキャッシュも「使用中」に含めるため高く出がちです。Linux は空きメモリをキャッシュに使うので、これだけで不足とは判断しません。見るべきは kbavail（新しく使える見込みの量）と、スワップの動きです。

sar -S：スワップの使用量と使用率
sar -W：pswpin/s / pswpout/s。秒あたりのスワップイン・アウト。0でない値が続くなら実際にメモリが足りていない
sar -B：majflt/s（ディスクからの読み込みを伴うページフォルト）が増えていれば、メモリ不足で読み直しが起きている

スワップの「使用量」があるだけなら、過去に追い出されたまま使われていないページのこともあります。問題になるのは、sar -W の値が継続して出ている状態です。

ディスク：sar -d -p

-p を付けると sda や nvme0n1 のようなデバイス名で表示されます。主な列は tps（秒あたりI/O回数）、rkB/s / wkB/s（読み書き量）、await（1回のI/Oにかかった平均時間）、aqu-sz（平均待ち行列）、%util（使用率）です。列名は sysstat のバージョンで変わることがあります。

await が普段より大きく伸びていれば、ディスクが詰まっています。%util は、複数の要求を並列に処理できる SSD / NVMe では上限近くに張り付いていても余力があることがあるため、await と合わせて判断します。

ネットワーク：sar -n DEV / sar -n EDEV

sar -n DEV でインターフェースごとの送受信量（rxkB/s / txkB/s）、sar -n EDEV でエラーやドロップを確認できます。アクセス集中や大容量ファイルの配信、バックアップ転送の時間帯を特定するのに使えます。

WordPress サーバーで遅延が起きたときの調べ方

「何時ごろ遅かった」が分かったら、その時間帯を前後30分ほど広めに取って、次の順に見ていきます。

sar -q：負荷が上がっていたか。上がっていなければ、サーバーよりも外部API・DNS・CDNなど外側の問題を疑う
sar -u：上がっていたなら、%user・%iowait・%steal のどれが増えたか
sar -W と sar -r：スワップが動いていたか。動いていれば PHP-FPM のプロセス数や MySQL のバッファ設定が搭載メモリに対して大きすぎる可能性
sar -d -p：await が伸びていたか。伸びていれば、バックアップ・ログローテーション・検索インデックス作成などの重いジョブがその時刻に動いていないか、crontab と照合する
sar -n DEV：通信量が急増していれば、アクセスログでボットや特定URLへの集中を確認する

sar は「何が足りなかったか」を教えてくれますが、「どのプロセスが原因か」までは分かりません。原因プロセスの特定には、その時刻のアクセスログ、PHP-FPM のスローログ、MySQL のスロークエリログを合わせて確認します。

記録を表計算やグラフで見る

sadf を使うと、記録をセミコロン区切りなどの形式で書き出せます。

# CPUの記録をセミコロン区切りで出力
sadf -d /var/log/sysstat/sa15 -- -u > cpu_sa15.csv

長期の推移を継続して見たい場合は、sar の記録を手作業で集めるより、Prometheus の node_exporter のようなメトリクス収集の仕組みを使うほうが向いています。sar は「各サーバーに入れておく、軽い記録係」として併用するのが現実的です。

よくあるつまずき

**Cannot open ... No such file or directory と出る**：記録が有効になっていないか、指定した日のファイルがありません。systemctl status sysstat とタイマーの状態、ファイルの置き場所を確認します。
履歴が数日分しかない：保存日数の設定 HISTORY が短いか、ディスク容量不足で消えている可能性があります。
短いスパイクが見えない：収集間隔より短い現象は平均に埋もれます。調査中だけ sar -u 1 60 のように手動で細かく取るか、収集間隔を短くします。

まとめ

sar は sysstat の記録を読み、過去の時刻を指定してCPU・メモリ・I/O・ネットワークを振り返れる
導入後に記録を有効にした時点から履歴が残るため、平常時から入れておく
CPU は %iowait と %steal、メモリは kbavail とスワップの動き（sar -W）、ディスクは await を重点的に見る
遅延の調査は -q → -u → -W/-r → -d → -n の順に絞り込み、ログで原因プロセスを特定する
設定ファイルのパスや列名はディストリビューションとバージョンで異なるため、手元の man sar で確認する