sar(サー)
英語表記: sar (System Activity Reporter)
概要
sarは、LinuxなどのUNIX系サーバOSにおいて、CPU、メモリ、ディスクI/O、ネットワークなど、システム全体の詳細なアクティビティデータを継続的に収集し、レポートする強力なコマンドラインツールです。このツールは、サーバOS(Linux Server, Windows Server)のカテゴリの中でも、特に「リソース監視」と「サーバチューニングとパフォーマンス」の分野で中心的な役割を果たします。単に現在のリソース状況を確認するだけでなく、過去にわたるシステムの挙動を時系列で記録・分析するために利用され、システムの性能問題の特定やボトルネック解消に不可欠な「証拠」を提供します。
詳細解説
sarは、サーバの性能維持と改善を目指す「サーバチューニングとパフォーマンス」の工程において、データに基づいた意思決定を可能にするための根幹となるツールです。なぜなら、パフォーマンスの問題は一時的なスパイクであることも多く、リアルタイムの監視だけでは原因を特定できないことが多いからです。sarは、この課題を解決するために設計されています。
目的と動作原理
sarの主な目的は、システムリソースの利用状況を一定間隔でサンプリングし、その履歴データを永続的に保存することです。この履歴データがあることで、「昨日午後3時にサーバが遅くなったのはなぜか?」といった問いに、データに基づいて答えることができます。
sarは通常、sysstatパッケージの一部として提供されます。その動作は主に二つのコンポーネントによって支えられています。
-
sadc (System Activity Data Collector):
これは、実際のデータ収集を行うデーモンまたはプロセスです。sadcは、cronなどのスケジューラによって定期的に実行され、その時点のシステム統計情報を取得し、バイナリ形式のデータファイル(通常/var/log/sa/ディレクトリに日付ごとに保存されます)に書き込みます。このデータこそが、過去の性能分析の土台となります。 -
sar コマンド:
このコマンドは、sadcによって収集され保存されたバイナリデータを読み込み、人間が理解しやすいテキスト形式のレポートとして出力する役割を担います。特定の時間帯を指定したり、CPU、メモリ、ディスクI/Oなど、レポートするメトリクス(指標)を選択したりできます。
リソース監視におけるsarの重要性
「リソース監視」の観点から見ると、sarは非常に多岐にわたる重要なメトリクスを提供します。
- CPU使用率: ユーザープロセス、システムプロセス、I/O待機(iowait)などの内訳を詳細に把握できます。特に
iowaitが高い場合、ディスクI/Oがボトルネックになっている可能性を強く示唆します。これは、チューニングの方向性を決定づける重要な手がかりとなります。 - メモリとスワップ: メモリの使用状況、キャッシュの利用状況、そしてスワップアウト/スワップインの頻度を監視します。スワップが頻繁に発生している場合、物理メモリ不足が性能低下の直接的な原因であることがわかります。
- ディスクI/O: ディスクの読み書き速度、待ち行列の長さ(キューの深さ)などを確認できます。これにより、特定のストレージが限界に達していないか判断できます。
- ネットワーク: ネットワークインターフェースごとのパケット送受信数やエラー率を監視し、ネットワークレベルでの問題(例:輻輳、ハードウェア障害)の可能性を探ります。
このように、sarはシステム全体を鳥瞰し、パフォーマンス問題がどこに根差しているのかを特定するための「高性能な診断装置」として機能するのです。サーバOSを運用する上で、このデータがなければ、チューニングは単なる勘頼りになってしまいます。
具体例・活用シーン
sarは、特に原因不明のパフォーマンス低下やキャパシティプランニング(将来的なリソースの見積もり)において、その真価を発揮します。
1. ボトルネックの特定
ある日、Webサーバの応答速度が急に低下したとします。リアルタイム監視ではCPU使用率が一時的に跳ね上がったことしかわかりませんでした。
- 活用シーン: sarの履歴データを確認し、応答が遅くなった時間帯(例:14:00〜14:15)を指定して、CPU、I/O、ネットワークの各レポートを順にチェックします。
- もし、その時間帯の
%iowait(I/O待ち)が普段の5%から30%に急増していた場合、原因はCPU負荷ではなく、データベースへのアクセス集中や、ログの書き込み過多など、ディスク関連の処理待ちにあると断定できます。これにより、チューニングの焦点をアプリケーションのI/O処理改善に移すことができます。
2. サーバの健康診断書(フライトレコーダーの比喩)
sarが収集するデータは、サーバにとっての「フライトレコーダー」のようなものだと考えると、その重要性がよくわかります。
飛行機が事故を起こしたとき、調査官はフライトレコーダーを回収し、事故直前の操縦士の操作、エンジンの状態、高度、速度といった詳細なデータを分析します。これにより、何が起きたのか、そしてなぜ起きたのかを正確に再現できます。
サーバも同様です。システム障害や予期せぬ性能劣化が発生した際、運用担当者はパニックになりがちですが、sarデータ(フライトレコーダー)があれば、問題発生の数分前、数時間前のサーバの「体調」を正確に再生できます。
- 「障害発生時、メモリは枯渇していたのか?」
- 「CPUは限界まで使われていたのか?」
- 「それともネットワークが異常なトラフィックに晒されていたのか?」
sarのレポートを分析することで、これらの疑問に客観的に答えることができ、再発防止策を論理的に構築することが可能になります。これは、感覚的な運用から脱却し、科学的な「サーバチューニングとパフォーマンス」を実現するための第一歩なのです。
3. キャパシティプランニング
新しいサービスを立ち上げる際、現在のサーバがどれだけの負荷に耐えられるか、あるいは次にリソースを増強するタイミングを判断するためにsarデータが使われます。
- 活用シーン: ピーク時のリソース使用率(CPUやメモリ)を継続的に監視し、例えば「CPU使用率が平均80%を超えたら増強を検討する」といった基準を設定します。sarの長期的なトレンド分析により、現在のリソースがいつ限界に達するかを予測し、計画的なハードウェア増強や仮想リソースのスケールアップを行うことができます。
資格試験向けチェックポイント
IT資格試験、特に基本情報技術者試験や応用情報技術者試験において、「サーバチューニングとパフォーマンス」および「リソース監視」の概念は頻出テーマです。sarコマンド自体が直接問われることは稀ですが、sarが提供する指標や、その利用目的が知識として要求されます。
- リソース監視の目的: 性能評価の三要素(スループット、レスポンスタイム、ロードアベレージ)を改善するために、リソースのボトルネック(CPU、メモリ、I/O、ネットワークのいずれか)を特定することが重要である、という文脈でsarの役割が問われます。
- チェックポイント: sarは、ボトルネック特定のための「過去データ分析ツール」である、と認識しておきましょう。
- I/O待機時間(iowait): sarが出力するCPU使用率の内訳に含まれる
iowaitは、ディスクI/Oのボトルネックを示す重要な指標として理解しておく必要があります。これが高ければ、CPU自体ではなく、ストレージの読み書きが原因で処理が滞っていることを意味します。 - スワッピングの指標: sarで確認できるスワップアウト/スワップインの発生は、メモリ不足の明確な兆候です。これが頻繁に発生している場合、システムの全体的なパフォーマンスが著しく低下している状態(スラッシング)を示しており、メモリ増設などの対策が必要になります。
- 関連ツールとの区別:
topやhtopがリアルタイムの現在状況を確認するのに対し、sarは「過去の履歴」を分析するために使われる、という機能の違いを理解しておくと、選択肢問題で役立ちます。
応用情報技術者試験では、性能測定結果の分析問題として、sarが出力するような形式のデータ(CPU使用率の内訳やI/O統計)が示され、そこから性能問題の原因を推測させるパターンが考えられます。
関連用語
- 情報不足
- (補足) sarはLinux環境で非常に一般的ですが、同等の機能を持つWindows Serverのパフォーマンス監視ツールとしては「パフォーマンスモニター (PerfMon)」があります。しかし、本記事ではsarに焦点を当てているため、この文脈での直接的な関連用語として、特に言及すべき情報が不足しています。強いて挙げれば、sarのデータ収集機能を提供する
sadc、またはリソース監視の一般的な概念である「ロードアベレージ」「スループット」「ボトルネック」といった用語が関連します。
