パフォーマンスを極める：Sysstatツールセット実践ガイド
この実践ガイドで、Sysstatツールセットを使ったLinuxパフォーマンス監視の可能性を最大限に引き出しましょう。Sysstatのインストールと履歴ログの設定方法、強力な`sar`ユーティリティの使い方を習得できます。CPU使用率、メモリ負荷、ディスクI/O飽和、ネットワークアクティビティを分析するための実用的なコマンド例を提供し、管理者がパフォーマンスベースラインを確立し、本番環境のボトルネックを迅速に診断・解決できるようにします。
パフォーマンスを極める：Sysstatツールセット実践ガイド
現在の瞬間だけしか見えないと、パフォーマンスの問題は混乱します。サーバーが今遅いのは分かっても、10分前も遅かったのでしょうか？ディスクのバックアップはCPU上昇の前に始まったのでしょうか？問題はcronジョブ、デプロイ、バックアップウィンドウの後に発生したのでしょうか？sysstatツールセットは、ライブの読み取り値と比較可能な履歴記録の両方を提供するため、非常に便利です。
主要なツールはsar、System Activity Reporterです。topでは情報が足りない場合、インシデントが過ぎ去った後、または問題がストレージ、メモリ負荷、ネットワークトラフィック、CPU飽和のいずれかであることを症状から推測するのではなく示す必要がある場合に、私はこれを使います。スイートの残りの部分、特にiostatとmpstatは、sarがボトルネックの可能性を指し示したときに詳細を補完します。
これは完全な可観測性の代替ではありません。アプリケーションメトリクス、ログ、トレーシング、外部チェックは依然として必要です。しかし、Linuxホストでは、sysstatは最初の実用的な質問「マシンは実際に何をしていたのか？」に答える最も速い方法の1つです。
1. Sysstatのインストールと初期設定
sysstatパッケージは、通常、主要なLinuxディストリビューションの標準リポジトリで利用可能です。
1.1 インストールコマンド
システムに適したパッケージマネージャーコマンドを使用します：
Debian/Ubuntu:
sudo apt update
sudo apt install sysstat
RHEL/CentOS/Fedora:
sudo yum install sysstat
# または新しいシステムではdnfを使用
sudo dnf install sysstat
1.2 履歴データ収集の有効化
sarを真に有用にするには、履歴データを収集する必要があります。デフォルトでは、インストール時にcronジョブやsystemdタイマーが設定されることが多いですが、確認が重要です。
最新のシステムでは、sysstatサービスがアクティブであることを確認します：
sudo systemctl enable --now sysstat
設定ファイル
データ収集の頻度は設定ファイルで制御され、通常は/etc/default/sysstat（Debian/Ubuntu）または/etc/sysconfig/sysstat（RHEL/CentOS）にあります。ENABLEDまたはHISTORY設定を探します。ENABLED="true"に設定すると、毎日のデータ収集が有効になります。
ヒント： デフォルトでは、
sysstatデータファイルは/var/log/sa/に保存され、ファイル名はsaXX（XXは月の日付）です。一部のDebianベースのシステムでは、レポートが/var/log/sysstat/の下にも公開されます。パスを想定する前に、パッケージのデフォルトを確認してください。
収集を有効にした後、少なくとも1つの間隔を待って、ファイルが表示されていることを確認します：
ls -lh /var/log/sa/
ディレクトリが空の場合は、systemdタイマーを確認します：
systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer
古いシステムでは、収集は依然としてcronによって駆動される場合があります。正確なパッケージングはディストリビューションによって異なるため、別のサーバーからの記憶に頼るのではなく、確認してください。
2. コアユーティリティ：System Activity Reporter（sar）
sarは統計情報を表示するための主要なインターフェースです。リアルタイムデータを表示したり、以前に収集された履歴データを分析したりできます。
2.1 リアルタイム監視の基本構文
基本構文は、指定された間隔で定義された回数、特定のメトリクスを報告するように設計されています。
sar [options] [interval] [count]
例： 3秒ごとに10回、一般的なCPU統計を報告する場合：
sar -u 3 10
このコマンドはインシデント中に便利です。1回のスナップショットではなく、短い移動サンプルを提供するからです。1行だけでは静かな秒を捉えて誤解を招く可能性があります。30秒間の10サンプルで、パターンが安定しているか、スパイク状か、すでに終了しているかがわかります。
| オプション | 説明 |
|---|---|
-u |
CPU使用率（デフォルト） |
-r |
メモリとページング統計 |
-d |
ブロックデバイスアクティビティ（ディスクI/O） |
-n |
ネットワーク統計（例：インターフェース統計には-n DEV） |
-q |
実行キューとロードアベレージ |
-W |
スワップアクティビティ（ページング） |
-A |
すべてのメトリクス（包括的なスナップショットに便利） |
履歴ファイルの場合、形状は同じです。データファイルを選択するために-fを追加し、時間範囲を制限するために-sと-eを追加することがよくあります。これは、障害発生中に1日分の出力全体を読むのは遅くてノイズが多いため重要です。
3. 主要なパフォーマンスメトリクスと実用的なsarの例
sarの出力を理解するには、どのメトリクスがパフォーマンスの健全性やストレスを示すかを知る必要があります。
3.1 CPU使用率（sar -u）
CPU使用率は、ボトルネックを探す際に最初に見る場所であることがよくあります。特定のカテゴリにわたる高い使用率は、ワークロードの性質を示します。
sar -u 5 3
| メトリクス | 説明 | ボトルネック指標 |
|---|---|---|
%user |
ユーザーレベルプロセスの実行に費やされたCPU時間。 | 高い場合、アプリケーション/サービスの飽和を示します。 |
%system |
カーネル/システムタスクの実行に費やされたCPU時間。 | 高い場合、集中的なシステムコールやドライバーの問題を示唆します。 |
%iowait |
I/O操作（ディスク/ネットワーク）を待機してアイドル状態だったCPU時間。 | 高い場合、CPU不足ではなくI/Oボトルネックを示します。 |
%idle |
何も待たずに費やされたCPU時間（利用可能）。 | 低い場合（例：< 5%）、CPU飽和を示唆します。 |
%iowaitには注意してください。これは「CPUがディスクでビジー状態」と誤解されることがよくあります。実際には、少なくとも1つのI/O要求が未処理の間にCPUがアイドル状態だったことを意味します。高い値はストレージレイテンシーを指し示す可能性がありますが、ディスクメトリクスで確認する必要があります。例えば、データベースサーバーでは、高い%iowaitと高いディスクawaitの組み合わせは、%iowait単独よりもはるかに強力なシグナルです。
もう1つの便利なCPUビューは実行キューです：
sar -q 5 5
runq-szは、実行を待機しているタスクの数を示します。ロードアベレージが高いがrunq-szが控えめで%iowaitが高い場合、純粋なCPU負荷ではなく、ブロックされたI/Oを見ている可能性があります。runq-szが高く、%idleがほぼゼロの場合、マシンはおそらく実行可能なプロセスを減らすか、より高速なコード、またはより多くのCPU容量を必要としています。
3.2 メモリとページング（sar -r と sar -W）
メモリ統計は、消費量とシステムがスワッピングやページングに頼っているかどうかの両方を明らかにします。
メモリ使用率（sar -r）：
sar -r 1 5
kbavail（利用可能なメモリ）に注目します。kbmemfreeが低くても、kbcachedとkbbuffersが高い場合、メモリはカーネルのキャッシュメカニズムによって効率的に使用されています。
スワッピングアクティビティ（sar -W）：
sar -W 1 5
pswpin/s（スワップインされたページ数）とpswpout/s（スワップアウトされたページ数）を確認します。ここで有意な非ゼロ値は、システムが積極的にスワッピングしていることを示し、メモリ負荷（強力なボトルネック）を示します。
Linuxのメモリ出力は、キャッシュが無駄なメモリではないことを覚えていなければ、驚くように見えることがあります。kbmemfreeが非常に少ないサーバーでも、kbavailが快適でスワップアクティビティが静かであれば、健全である可能性があります。危険なパターンは異なります：利用可能なメモリが低下し、スワップイン/アウトアクティビティが現れ、アプリケーションのレイテンシーが上昇します。これは、プロセスがRAMに収まらなくなったメモリにアクセスしていることを示します。
Webサーバーの場合、これはワーカー数を誤って2倍にするデプロイ後に発生する可能性があります。バッチホストの場合、2つの大きなジョブが重なったときに発生する可能性があります。sarはどのプロセスが原因かを教えてくれませんが、タイムラインを提供します。ps、top、サービスログ、またはcgroupメトリクスと組み合わせて、所有者を特定します。
3.3 ディスクI/Oアクティビティ（sar -d）
ディスクアクティビティの監視は、データベースサーバーや高負荷のストレージシステムにとって重要です。
sar -d 3 5
この出力では、特定のデバイス（例：sda、vda）を識別する必要があります。主要なメトリクスは次のとおりです：
tps：1秒あたりの転送数（高い値は高いI/O要求を示します）。rd_sec/sとwr_sec/s：1秒あたりに読み書きされたデータ量。%util：デバイスが要求の処理にビジーだった時間の割合。従来のブロックデバイスで%utilが100%近くにとどまる場合、ストレージが飽和している可能性があります。
最新のSSDや仮想ディスクでは、%utilは文脈を必要とします。一部のデバイスは並列I/Oを適切に処理し、クラウドボリュームはプロビジョニングされたIOPS、スループット、またはバーストクレジットによって制限される場合があります。%utilを完全な診断ではなく、より詳しく調べるためのプロンプトとして扱います。iostat -xd、アプリケーションレイテンシー、およびAWS、Azure、GCP、または他の仮想化環境にいる場合はプラットフォームレベルのストレージメトリクスで確認します。
実用的なワークフローの1つは次のとおりです：
sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5
sarを使用して悪い時間帯を見つけ、その後、ライブの再発中にiostatを使用してデバイスレベルのレイテンシーを検査します。
3.4 ネットワーク統計（sar -n）
sarは、さまざまなネットワーク層にわたるアクティビティを報告できます。最も一般的なチェックはインターフェースアクティビティ（DEV）です。
sar -n DEV 5 1
このコマンドは、各ネットワークインターフェースのrxpk/s（1秒あたりの受信パケット数）やtxkB/s（1秒あたりの送信キロバイト数）などのメトリクスを表示します。これを使用して、高負荷や潜在的なエラーが発生しているインターフェースを特定します。
エラーカウンターについては、EDEVを追加します：
sar -n EDEV 5 3
これにより、ドライバーでサポートされている場合、受信エラー、送信エラー、ドロップ、衝突が表示されます。ドロップは、サービスが断続的なタイムアウトを訴えているが、CPUとディスクが正常に見える場合に特に便利です。トラフィックスパイク中にドロップが増加する場合、NICキュー、カーネルネットワーク設定、コンテナネットワーキング、またはロードバランサーパスを検査する必要があるかもしれません。
TCPレベルの動作については、次を試してください：
sar -n TCP,ETCP 5 3
再送信、リセット、および失敗した接続試行は、漠然とした「サイトが遅い」という報告を、より具体的なネットワークまたは上流の問題に変えることができます。
4. 履歴分析とベースライン作成
sysstatの真の力は、長期間にわたるシステムアクティビティを分析する能力にあり、これはパフォーマンスベースライン（システムにとって正常とは何か）を確立するために不可欠です。
4.1 過去の日の分析
前日に収集されたデータを表示するには、-fフラグを使用して毎日のsaXXファイルへのパスを指定します。
例： 当月の10日目のCPU統計を表示する場合：
sar -u -f /var/log/sa/sa10
その日の特定の時間枠にわたる統計を確認するには、-s（開始時刻）と-e（終了時刻）フラグを追加します（24時間形式を使用）。
# 10日目の14:00から16:30までのネットワーク統計を表示
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00
4.2 ベースラインの確立
- データ収集： 通常の高負荷期間と低負荷期間を通じて
sysstatを実行します。 - 基準の特定： 履歴データ（
sar -f）を分析して、平均CPU使用率（%user、%system）、ピークI/Oレイテンシー（%util）、平均メモリ使用量を特定します。 - しきい値の定義： 独自のベースラインからの持続的な逸脱を調査トリガーとして扱います。ビジーなデータベースホストと静かなジャンプボックスは、同じしきい値を共有すべきではありません。
ベースラインは、実際のビジネスリズムに関連付けられているとより有用です。月曜朝のバッチインポート、夜間バックアップ、製品ローンチはすべて異なる「正常」な形状を作り出します。調査時にメモを残してください：「バックアップは01:00に開始」、「新しいリリースは14:30に」、「マーケティングメールは09:05に」。これらのメモにより、後で履歴sar出力を解釈するのがはるかに簡単になります。
5. 補助的なSysstatツール
sarは包括的なツールですが、sysstatスイートには、焦点を絞った詳細なレポートを提供する専門のユーティリティが含まれています。
5.1 iostat（入出力統計）
iostatは、特にストレージボトルネックの診断に役立つ、デバイス使用率に焦点を当てた詳細なメトリクスを提供します。
# 2秒ごとに4回、拡張統計（x）を含むディスク統計を報告
iostat -xd 2 4
主要なiostatメトリクス：
%util：I/O要求がデバイスに発行されたCPU時間の割合（飽和の重要な指標）。await：デバイスに発行されたI/O要求の平均待機時間（ミリ秒）。高いawaitはストレージの応答性が低いことを示します。
awaitが急上昇してもスループットが高くない場合、小さなランダムI/O、ファイルシステムの問題、仮想インフラストラクチャ上のノイジーネイバー、または同期書き込みが多いアプリケーションを探します。スループットが高く、それに伴ってレイテンシーが上昇する場合、デバイスが単に実用的な限界に達している可能性があります。
5.2 mpstat（マルチプロセッサ統計）
CPUスケジューリングの問題やコア間の不均一なワークロード分散が疑われる場合、mpstatはプロセッサごとの使用率統計を提供します。これはsar -uが集約するものです。
# 2秒ごとにすべてのCPU（A）の使用率を表示
mpstat -P ALL 2 1
これは、他のコアがアイドル状態である間に単一のコアを飽和させているシングルスレッドアプリケーションを特定したり、ハイパースレッディングの効率を診断したりするのに非常に役立ちます。
5.3 sadf（Sysstatデータのエクスポート）
sadfはsarと同じ収集データを読み取りますが、スクリプトやダッシュボードで消費しやすい形式で出力できます。
sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r
-d出力は、区切りテキスト処理に便利です。-j出力は、JSONが必要な場合に便利です。これは、インシデントレビューに証拠を添付したり、手動でターミナル出力をコピーせずに2つのホストを比較したりする場合に便利です。
6. 実践的なインシデントウォークスルー
10:15にタイムアウトし始めたAPIサーバーを想像してください。アプリケーションログは要求が蓄積していることを示していますが、理由は説明していません。履歴CPUビューから始めます：
sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
%userが高く%idleが低い場合、アプリはCPUバウンドである可能性があります。コアごとの使用率を確認します：
sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
1つのコアが固定され、他のコアが静かな場合、シングルスレッドワーカー、ホットロック、または不均一なプロセス分散を疑います。すべてのコアがビジーな場合、要求レート、最近のデプロイ、および高価なコードパスを調べます。
CPUがほとんどアイドル状態で%iowaitが上昇している場合、ディスクに切り替えます：
sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
同じ時間帯の高いデバイス使用率または上昇するキューの深さは、ストレージを指し示します。データベースバックエンドサービスでは、次のステップはデータベースログとスロークエリデータです。ファイル提供ホストでは、バックアップ、圧縮ジョブ、またはログローテーションが同時に実行されたかどうかを確認します。
CPUとディスクが正常に見える場合、メモリとネットワークを検査します：
sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
重要なのは、毎回すべてのコマンドを実行することではありません。証拠に従うことです。sarはリソースクラス全体のタイムラインを提供し、通常は最も騒がしい症状を追いかけるのをやめるために必要なものです。
シンプルな運用習慣
sysstatを学ぶ最善の方法は、何かが壊れる前に使用することです。通常のトラフィック時に健全なサーバーを確認します。バックアップ中に確認します。デプロイ後に確認します。環境に合ったいくつかのコマンドパターンを保存します。
インシデントが発生したとき、正常がどのようなものかをすでに知っているでしょう。それがツールセットの真の価値です。sar、iostat、mpstat、sadfはアプリケーションを魔法のように診断するわけではありませんが、会話を証拠に基づいて行います：問題がいつ始まったか、どのリソースが変化したか、ホストが実際に負荷を受けていたかどうか。