「サーバーが重いけど、原因がどこにあるのか分からない…」そんな経験はありませんか? CPUなのか、メモリ不足なのか、それともディスクI/Oやネットワーク帯域の問題なのか・・・
サーバーの性能トラブルを突き止めるには、瞬間的な状態ではなく、時間の経過による変化を追いかけることが重要です。そんなときに役立つのが「sarコマンド」です。
sarはLinuxに標準的に導入されることが多い「sysstat」パッケージに含まれており、CPUやメモリ、ディスク、ネットワークといったリソース利用状況を定期的に収集・記録してくれる便利なツールです。
しかも、過去の履歴をさかのぼって分析できるため、突発的な障害の原因調査や、リソース不足の兆候を早めに把握することが可能になります。
この記事では、sarコマンドの基本から長期監視の設定方法、そして実践的な活用例までをわかりやすく解説していきます。
Linuxの基礎知識 🟢基本操作系 🟡 ログ・監視系 🔵 プロセス・サービス系 🟣 ネットワーク系 🔴 ディスク・ファイル系 🟤 セキュリティ・運用系 🟠 仮想化・バックアップ
📌 Linux環境を扱うための最初のステップを学ぶ入門カテゴリ
📌 システムの健全性を保つためのログ活用と監視テクニック
└─【Linuxの基礎知識】ログ・監視系まとめ:システム安定運用の必須テクニック
├─ 【Linuxの基礎知識】リソース監視ツールの使い方を徹底解説!
├─ 【Linuxの基礎知識】journalctlの具体的な使い方を初心者向けに解説
├─ 【Linuxの基礎知識】Linuxでログ肥大を防ぐlogrotateの基本と自作アプリ対応法
├─ 【Linuxの基礎知識】dmesgの読み方とハードウェアトラブル対応
├─ 【Linuxの基礎知識】vmstatとiostatでボトルネックを見抜く
├─ 【Linuxの基礎知識】sarコマンドでサーバー性能を長期監視する方法
├─ 【Linuxの基礎知識】top / htopの違いと使い分け|リアルタイム監視の基本
└─ 【Linuxの基礎知識】rsyslogでログを転送する方法と設定例
📌 サービスを安定稼働させるためのプロセス管理と制御の基本
📌 ネットワーク通信を理解しトラブルを解決するための実践知識
📌 データを守り効率的に扱うためのストレージ管理スキル
📌 安全なシステム運用を実現するためのアクセス制御と防御策
📌 柔軟な環境構築とリスク対策を両立する仮想化とバックアップ技術
sarコマンドとは
sarコマンドはLinuxに標準的に導入されることが多い「sysstat」パッケージに含まれる監視ツールです。CPUやメモリ、ディスクI/O、ネットワークといったリソースの利用状況を定期的に収集・記録することができます。
瞬間的な値ではなく履歴としてデータを残せるため、サーバーの性能分析や障害調査に大きく役立ちます。
sarコマンドの基本概要
sarはSystem Activity Reportの略で、サーバーの動作状況を継続的に監視することを目的としたコマンドです。単発の監視だけでなく、定期的にデータを記録してくれるため、長期的なリソース使用傾向を把握することが可能です。
導入は簡単で、RHEL系Linuxでは「sysstat」パッケージをインストールするだけで利用できます。
yum install -y sysstat
sarコマンドを実行した際に「/var/log/sa/saXX を開けません: そのようなファイルやディレクトリはありません」と表示されることがあります。これはsar自体はインストールされているものの、データ収集が無効になっており、統計ファイルが生成されていない状態です。
この場合は設定ファイルとサービスの有効化を確認する必要があります。
確認と有効化の流れ
- sysstatのtimer確認
systemctl list-timers | grep sysstat
ここで sysstat-collect.timer や sysstat-summary.timer が表示されていなければ無効になっています。 - timerを有効化
systemctl enable --now sysstat-collect.timer
systemctl enable --now sysstat-summary.timer - 数分待ってから動作確認(10分後)
sar -u
この設定を行うと、cronまたはsystemd timerによって1分ごとにデータ収集が行われます。
数分待ってから再度sarコマンドを実行すれば、/var/log/sa 配下にsaXXファイルが作成され、正常に出力を確認できるようになります。
sysstat-collect.timer は 10分ごとに sa1 を実行して統計を記録します。
そのため 有効化した直後に sar -u を叩いてもファイルが無い → 「開けません」というエラーが出ます。
10分経過すれば /var/log/sa/sa03(今日の日付のファイル)が自動で作成されます。
sarが収集できる情報の種類
sarではCPU使用率やメモリ利用率だけでなく、ディスクI/Oやネットワーク帯域など幅広い情報を取得できます。
これにより、障害発生時にどのリソースがボトルネックになっているかを迅速に切り分けることができます。
カテゴリ | 取得できる情報 |
---|---|
CPU | ユーザーモード、システムモード、アイドル時間など |
メモリ | 空きメモリ、使用中メモリ、スワップ状況 |
ディスク | 読み書き回数、I/O待機時間 |
ネットワーク | 送受信パケット数、エラー数 |
サーバー性能監視にsarを使うメリット
sarを利用することで、サーバーの状態を長期的に把握でき、トラブル発生時の原因分析に役立ちます。さらに、障害の予兆を早期に検知することで未然に対策を講じることも可能です。
特に複数ユーザーが利用する環境や、稼働率の高いサーバーにおいては、sarによる継続的な監視が安定運用に直結します。
sarコマンドの導入手順
sarコマンドを利用するためには、まず「sysstat」パッケージを導入する必要があります。RHEL系Linuxであれば標準リポジトリから簡単にインストールでき、導入後すぐに利用可能です。
ここではインストール手順と基本的な使い方を解説します。
sysstatパッケージのインストール方法
sarはsysstatパッケージに含まれており、インストールすれば利用可能になります。
RHEL系Linuxであれば以下のコマンドで導入できます。
yum install -y sysstat
インストール後、デフォルトでは収集機能が無効になっている場合があります。そ
の場合は、設定ファイルを修正し、サービスを有効化する必要があります。
vi /etc/sysconfig/sysstat
設定ファイル内の以下の項目を「true」に変更してください。
ENABLED="true"
その後、sysstatサービスを起動します。
systemctl enable --now sysstat
sarコマンドの基本的な使い方
sarコマンドはオプションを指定することで、CPUやメモリ、ディスク、ネットワークといったリソースの利用状況を表示できます。
オプションに応じて表示内容が切り替わるため、用途に合わせて使い分けます。
オプション | 監視対象 | 内容 |
---|---|---|
-u | CPU使用率 | ユーザー、システム、アイドル時間などCPU利用状況を表示 |
-r | メモリ使用状況 | 空きメモリ、使用中メモリ、スワップ利用状況を表示 |
-b | ディスクI/O | ディスクの読み書き回数、I/O待機時間などを表示 |
-n DEV | ネットワーク帯域 | ネットワークデバイスごとの送受信パケット数やエラー数を表示 |
CPU使用率を確認する
CPU使用率はユーザー、システム、アイドル時間などに分かれて表示され、どのプロセス領域に負荷が集中しているかを把握できます。
sarコマンドに「-u」オプションを指定すると、CPUの使用状況を確認できます。ユーザー処理やシステム処理、I/O待機などにCPUがどの程度割り当てられているかを分析でき、サーバーの処理能力に余裕があるかを判断する材料になります。
以下の例では5秒間隔で3回分のCPU使用率を表示します。
sar -u 5 3
出力例:
12:01:01 AM CPU %user %nice %system %iowait %steal %idle 12:01:02 AM all 75.30 0.10 10.15 5.20 0.00 9.25
各項目の意味は以下の通りです。
項目 | 名称 | 内容 |
---|---|---|
%user | User CPU time | ユーザープロセスが使用しているCPU時間の割合 |
%nice | Nice CPU time | nice値を持つユーザープロセスが使用しているCPU時間の割合 |
%system | System CPU time | カーネルやシステム処理に割り当てられたCPU時間の割合 |
%iowait | I/O wait time | I/O操作の完了を待機しているCPU時間の割合。高い場合はディスクI/Oがボトルネックの可能性 |
%steal | Steal time | 仮想環境で他のゲストOSに奪われたCPU時間の割合。物理環境では通常0 |
%idle | Idle time | アイドル状態のCPU時間の割合。CPUに余裕がある場合はこの値が大きくなる |
メモリ使用状況を確認する
sarコマンドに「-r」オプションを指定することで、サーバーのメモリ利用状況を確認できます。メモリ不足やスワップ発生の兆候を把握するのに役立ちます。
空きメモリやスワップの利用状況など、メモリ関連のリソースを把握するのに役立ちます。
sar -r 5 3
出力例:
12:01:01 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 12:01:02 AM 102400 819200 88.9 20480 163840 950000 110.5 600000 150000 120
主な項目の意味は次の通りです。
項目 | 名称 | 内容 |
---|---|---|
kbmemfree | Free memory | 空きメモリ容量(KB単位) |
kbmemused | Used memory | 使用中メモリ容量(KB単位) |
%memused | Memory used percentage | メモリ使用率(全体に対する割合) |
kbbuffers | Memory buffers | バッファとして使用されているメモリ容量 |
kbcached | Cached memory | キャッシュとして使用されているメモリ容量 |
kbcommit | Committed memory | プロセスに割り当て予約された合計メモリ容量 |
%commit | Commit percentage | コミット済みメモリが物理メモリに対してどれくらいの割合か |
kbactive | Active memory | 現在アクティブに使用されているメモリ容量 |
kbinact | Inactive memory | アイドル状態だがまだ解放されていないメモリ容量 |
kbdirty | Dirty memory | まだディスクに書き込まれていない変更データを保持しているメモリ容量 |
ディスクI/Oを確認する
sarコマンドでは「-b」オプションを指定することで、ディスクI/Oの統計情報を確認できます。I/Oがボトルネックになっているかどうかを判断する上で重要な指標です。
I/O要求数や待機時間を把握することで、ディスクがボトルネックになっていないかを判断できます。
sar -b 5 3
出力例:
12:01:01 AM tps rtps wtps bread/s bwrtn/s 12:01:02 AM 950 800 150 20480 16384
主な項目の意味は次の通りです。
項目 | 名称 | 内容 |
---|---|---|
tps | Transfers per second | 1秒あたりのI/Oリクエスト総数。ディスク全体の負荷状況を示します。 |
rtps | Read transfers per second | 1秒あたりの読み込みリクエスト数。読み込み集中の有無を確認できます。 |
wtps | Write transfers per second | 1秒あたりの書き込みリクエスト数。書き込み処理が増えると遅延の原因になります。 |
bread/s | Blocks read per second | 1秒あたりに読み込まれたブロック数。ディスク読み込み量の指標です。 |
bwrtn/s | Blocks written per second | 1秒あたりに書き込まれたブロック数。ディスク書き込みの負荷状況を示します。 |
ネットワーク帯域を確認する
sarコマンドに「-n DEV」オプションを指定することで、ネットワークデバイスごとのパケットやデータ量の統計を確認できます。通信が正常に行われているか、エラーや異常が発生していないかを把握するのに有効です。
ネットワークの送受信パケット数やエラー数を確認することで、通信が正常に行われているかどうかを分析できます。
以下の例ではデバイスごとのパケット送受信状況を表示します。
sar -n DEV 5 3
出力例:
12:01:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:01:02 AM eth0 5000 4800 10240 8192 0 0 5
各項目の意味は以下の通りです。
項目 | 名称 | 内容 |
---|---|---|
IFACE | Interface | インターフェース名(例: eth0, ens192 など) |
rxpck/s | Received packets per second | 1秒あたりの受信パケット数 |
txpck/s | Transmitted packets per second | 1秒あたりの送信パケット数 |
rxkB/s | Received kilobytes per second | 1秒あたりに受信したデータ量(KB単位) |
txkB/s | Transmitted kilobytes per second | 1秒あたりに送信したデータ量(KB単位) |
rxcmp/s | Compressed packets received per second | 1秒あたりの受信圧縮パケット数 |
txcmp/s | Compressed packets transmitted per second | 1秒あたりの送信圧縮パケット数 |
rxmcst/s | Multicast packets received per second | 1秒あたりのマルチキャスト受信パケット数 |
さらに rxmcst/s が継続的に高い場合はネットワーク構成やアプリケーション動作を確認する必要があります。
sarコマンドによる長期監視の設定
sarコマンドは一度実行するだけで現在のリソース状況を確認できますが、長期監視を行うためには定期的にデータを収集し、履歴を保存しておくことが重要です。
Linuxではcronや専用サービスを利用して自動的に収集を行い、その結果をログファイルとして蓄積します。ここでは長期監視に必要な設定方法を解説します。
データ収集の仕組み(cronによる定期実行)
sarはsysstatサービスを利用してcronによる定期実行が行われます。インストール後、デフォルトで1分間隔でデータ収集が行われるよう設定されています。
設定内容は以下のファイルで確認できます。
vi /etc/cron.d/sysstat
このファイルには、sarコマンドを一定間隔で実行し、結果をsa形式のバイナリファイルとして保存する記述があります。
必要に応じて間隔を変更することで、より詳細なデータ収集や負荷を軽減した収集が可能です。
データ保存期間の設定方法
sarが収集したデータは一定期間保存されます。保存期間は設定ファイルで変更可能です。
以下の設定ファイルを編集してください。
vi /etc/sysconfig/sysstat
設定ファイル内の「HISTORY」値を変更することで、保持日数を指定できます。
HISTORY=28
上記の例では28日分のデータが保存されます。サーバーの運用ポリシーに応じて適切な日数を設定してください。
/var/log/sa ディレクトリの管理
収集されたデータは「/var/log/sa」ディレクトリに保存されます。日ごとにファイルが生成され、saXX(バイナリ形式)とsarXX(テキスト形式)として管理されます。
ls /var/log/sa
ファイル名 | 内容 |
---|---|
saXX | sarが収集したバイナリデータファイル(XXは日付) |
sarXX | saXXをもとに生成されたテキスト形式のレポート |
定期的にこのディレクトリを確認し、不要なファイルを削除することでディスク容量の圧迫を防ぐことができます。長期運用ではログ容量の管理も安定運用に欠かせません。
sarコマンドの実践的な活用例
sarコマンドは単純にリソースの使用状況を記録するだけでなく、トラブルシューティングや予兆検知に活用できます。
ここでは、具体的な出力例と危険な状態の目安を紹介します。
ボトルネック切り分けフロー
サーバーが遅いと感じたとき、闇雲に調査をするのではなく、sarコマンドで順序立てて原因を切り分けることが重要です。
以下は数値を基準にした簡易的な診断フローです。テキストベースのフローチャートとして整理することで、どのリソースを重点的に調べるべきかが明確になります。
切り分けフロー
サーバーが遅い?
↓
CPU使用率が高い?(sar -u)
↓ Yes → %user + %system > 90% → CPU過負荷
↓ No
I/O待ちが多い?(%iowait > 30%)
↓ Yes → sar -b で tps 確認 → ディスクI/Oボトルネック
↓ No
メモリ不足か?(sar -r)
↓ %memused > 90% または %swpused > 80% → メモリ逼迫
↓ No
ネットワーク異常か?(sar -n DEV)
↓ rxerr/s, txerr/s > 0 → NICや回線のトラブル
このようにフローとしてまとめておくと、数値を見ただけで「CPUかI/Oかメモリかネットワークか」を短時間で切り分けられるため、障害対応や性能調査の効率を大幅に高められます。
ボトルネックの特定方法
サーバーが遅いと感じたとき、どのリソースが原因かを切り分けることが重要です。sarで複数の項目を確認することで、CPU・メモリ・ディスク・ネットワークのどこに問題があるかを把握できます。
sar -u 1 3
出力例:
12:01:01 AM CPU %user %nice %system %iowait %steal %idle
12:01:02 AM all 72.50 0.05 12.30 4.80 0.00 10.35
12:01:03 AM all 75.10 0.02 11.90 5.15 0.00 7.83
12:01:04 AM all 74.60 0.03 10.50 6.20 0.00 8.67
Average: all 74.07 0.03 11.57 5.38 0.00 8.95
危険の目安:
危険の目安としては、%user と %system を合計した値が90%を超えて継続している場合には、CPU自体が過負荷の状態にあると判断できます。一方で %iowait が30%以上に達しているときは、CPUの処理能力が不足しているのではなく、ディスクI/Oの遅延がボトルネックになっている可能性が高いといえます。さらに %idle が常に5%未満に留まっている場合は、CPUにほとんど余裕がなく、性能限界に近い状態で稼働していることを意味します。これらの数値を総合的に確認することで、サーバーの遅延要因がCPU負荷にあるのか、あるいはI/O遅延にあるのかを切り分けることができます。
sar -b 1 3
出力例:
12:01:01 AM tps rtps wtps bread/s bwrtn/s
12:01:02 AM 950 800 150 20480 16384
12:01:03 AM 910 770 140 20000 16000
12:01:04 AM 925 780 145 20200 16100
Average: 928 783 145 20226 16161
危険の目安:
ディスクI/Oの統計を確認する際には、tps が異常に高い値で推移し、同時にCPU統計の %iowait が増加している場合に注意が必要です。これはディスクの処理能力が限界に近づいていることを示しており、I/O遅延がサーバー全体の性能低下を招いている可能性があります。rtps と wtps のバランスを見れば読み込みと書き込みのどちらに負荷が偏っているかが分かり、さらに bread/s や bwrtn/s の値が高止まりしている場合は、大量のブロック読み書きが発生していることを意味します。こうした状況が継続するようであれば、ディスク増設やI/O分散といった対応を検討するべきです。
異常検知のポイント
普段の稼働データを基準として、急激な変化を検知するのが重要です。
sar -r 1 3
出力例:
12:01:01 AM kbmemfree kbmemused %memused kbswpfree kbswpused %swpused
12:01:02 AM 102400 819200 88.9 512000 500000 97.6
12:01:03 AM 101800 819800 89.0 511500 500500 97.7
12:01:04 AM 101200 820400 89.2 511000 501000 97.8
Average: 101800 819800 89.0 511500 500500 97.7
危険の目安:
メモリ監視では %memused が90%を超えて長時間継続している場合、物理メモリが逼迫していると判断できます。さらに %swpused が80%以上に達している場合は、スワップ領域に過度の依存が発生しており、システム全体の処理速度が低下する危険があります。kbmemfree が急速に減少し続ける、あるいは kbswpfree が枯渇していくようであれば、アプリケーションのメモリリークや負荷増大の兆候と考えられます。こうした状態が継続する場合は、プロセスの調査やメモリ増設といった対策が必要です。
sar -n DEV 1 3
出力例:
12:01:01 AM IFACE rxpck/s txpck/s rxerr/s txerr/s
12:01:02 AM eth0 5000 4800 10 0
12:01:03 AM eth0 5200 4900 12 1
12:01:04 AM eth0 5100 4950 11 0
Average: eth0 5100 4883 11 0
危険の目安:
ネットワークの監視では、rxpck/s や txpck/s が通常より急激に増加している場合、過負荷や外部からの大量通信(DDoSなど)が疑われます。特に注意すべきは rxerr/s や txerr/s の項目です。これらは受信および送信エラーを示す値であり、通常はゼロであることが理想です。エラーが継続的に発生している場合は、NICやケーブルといった物理的な障害、あるいはネットワーク設定の不具合が原因である可能性が高いといえます。エラーが増え続ける場合は早急にハードウェアや設定の確認が必要です。
他の監視ツールとの組み合わせ
sar単体でも十分有効ですが、ZabbixやGrafanaなどの監視ツールと連携することで、数値の変化をグラフ化し、閾値を超えた場合にアラートを自動通知できます。これにより「数値が危険水準に達したタイミング」を即座に把握できるようになります。
監視対象 | オプション | 危険の目安 |
---|---|---|
CPU使用率 | -u | %user + %system が90%以上継続、または %iowait が30%以上 |
メモリ使用率 | -r | %memused が90%以上、または %swpused が80%以上 |
ディスクI/O | -b | tps が急増し、同時に %iowait が高騰 |
ネットワーク | -n DEV | rxerr/s・txerr/s が継続して発生 |
このように出力例と危険の目安を合わせて確認することで、sarを実運用に直結させることができます。
sarコマンド利用時の注意点
sarコマンドは長期的な監視に有効ですが、運用にあたってはいくつかの注意点があります。適切に管理しないと、サーバーに余計な負荷をかけたり、不要なログが蓄積してディスク容量を圧迫することがあります。
ここでは運用上のポイントを整理します。
ログ容量の管理
sarが収集するデータは「/var/log/sa」ディレクトリに日次ファイルとして保存されます。デフォルトでは28日間保持されますが、長期間運用しているとファイル数が増加し、ディスク容量を圧迫する可能性があります。
保持期間は設定ファイルで変更可能です。
vi /etc/sysconfig/sysstat
HISTORY=28
上記の「HISTORY」を適切な日数に変更することで、保持期間を調整できます。監査要件などで長期保存が必要な場合は、圧縮機能(COMPRESSAFTER)を併用するのも有効です。
sarが負荷に与える影響
sarは定期的にシステム情報を収集しますが、その処理は非常に軽量で、通常のサーバー運用に支障を与えることはほとんどありません。
ただし、収集間隔を極端に短く設定するとCPU負荷が増加し、逆にサーバー性能に影響を与える可能性があります。
一般的には1分間隔で十分であり、秒単位での設定は必要なケース以外では避けた方が良いでしょう。
トラブルシューティングの基本
sarコマンドを利用する際によくあるエラーとして「/var/log/sa/saXX を開けません」というものがあります。これはデータ収集が開始されていない場合に発生します。
RHEL8以降ではsystemd timerで収集を行うため、以下のように有効化する必要があります。
systemctl enable --now sysstat-collect.timer
systemctl enable --now sysstat-summary.timer
有効化後、初回の収集が実行されるまでファイルは生成されません。すぐに確認したい場合は、手動で収集を実行します。
/usr/lib64/sa/sa1 1 1
これで/var/log/saにsaXXファイルが作成され、sarコマンドが正常に利用できるようになります。
運用時にはこのような基本的なエラーと対応方法を把握しておくと、トラブル発生時の切り分けがスムーズになります。
まとめ
sarコマンドは、Linuxサーバーの性能を長期的に監視するために非常に有効なツールです。CPUやメモリ、ディスクI/O、ネットワークといった主要なリソースを定期的に記録し、障害発生時の原因調査や将来的なリソース不足の予兆検知に役立ちます。
導入はsysstatパッケージのインストールから始まり、systemd timerの有効化によって自動収集が行われます。収集されたデータは/var/log/saに保存され、必要に応じて保持期間や圧縮設定を変更することで効率的に管理できます。
また、sarコマンド単体での利用に加え、ZabbixやGrafanaなどの監視ツールと組み合わせることで、アラート通知や可視化分析といった運用高度化も可能です。日常の運用ではログ容量や収集間隔に注意しながら、安定した監視環境を維持することが重要です。
定期的なデータ収集と活用を通じて、サーバー障害の早期発見や性能改善につなげていくことができます。
▶︎ この記事を読んだら、次は 「top / htopの違いと使い分け|リアルタイム監視の基本」 を読むのがおすすめです!