サーバーが「遅い」と報告されたとき、何から調べればよいか迷った経験はないでしょうか。パフォーマンス監視は、CPU・メモリ・ディスク I/O・ネットワークの 4 大リソースを数値で把握し、ボトルネックを特定する作業です。本記事では、AlmaLinux 9 で使えるパフォーマンス監視コマンドを、sysstat の導入から tuned によるチューニング、OOM Killer の対処、物理・仮想サーバーそれぞれの固有監視項目、障害時の初動フローまで、実行例と出力の読み方つきでまとめています。入社 1〜3 年目のインフラエンジニアが、現場でそのまま使えるリファレンスとして活用できる構成です。
コマンド早見表
| 確認したい情報 | コマンド |
|---|---|
| sysstat 導入 | dnf install sysstat |
| CPU 使用率（リアルタイム） | sar -u 1 3 |
| CPU 使用率（過去データ） | sar -f /var/log/sa/saXX |
| プロセス一覧（CPU/メモリ順） | top -bn1 |
| CPU・メモリ・I/O 概況 | vmstat 1 3 |
| コア別 CPU 使用率 | mpstat -P ALL 1 |
| メモリ使用状況 | free -h |
| メモリ詳細 | cat /proc/meminfo |
| メモリ推移 | sar -r 1 3 |
| ディスク I/O 詳細 | iostat -xz 1 2 |
| ディスク I/O 推移 | sar -d 1 3 |
| inode 使用率 | df -i |
| プロセス別 CPU | pidstat -u 1 |
| プロセス別メモリ | pidstat -r 1 |
| プロセス別ディスク I/O | pidstat -d 1 |
| TCP/UDP コネクション数 | ss -s |
| リッスンポート一覧 | ss -tlnp |
| NIC 別トラフィック | sar -n DEV 1 3 |
| tuned プロファイル確認 | tuned-adm active |
| OOM Killer 発動履歴 | journalctl -k –grep=”Out of memory” |
| 仮想化種類の確認 | systemd-detect-virt |
前提条件
| 項目 | 値 |
|---|---|
| OS | AlmaLinux 9.6（Sage Margay） |
| sysstat | 12.5.4 |
| tuned | virtual-guest プロファイル適用中 |
| 仮想化 | Hyper-V（microsoft） |
| 実行ユーザー | 一般ユーザー（参照系）/ root（設定変更） |
1. sysstat の導入と sar
sar は、CPU・メモリ・ディスク I/O・ネットワークなどの統計情報を時系列で記録・表示するコマンドです。sysstat パッケージに含まれており、過去のデータを遡って参照できるため、障害調査で「いつから負荷が上がったのか」を特定する際に不可欠なツールです。
sysstat のインストールと有効化
sysstat パッケージをインストールし、データ収集サービスを有効化します。これにより、定期的にシステム統計が記録されるようになります。
実行コマンド：
# dnf install -y sysstat実行コマンド：
# systemctl enable --now sysstatデータ収集間隔の設定
sysstat のデータ収集間隔は /etc/cron.d/sysstat で管理されています。デフォルトでは 10 分間隔で sa1（データ収集）が実行され、1 日 1 回 sa2（日次サマリー作成）が実行されます。
- sa1：システム統計を収集し、
/var/log/sa/saXX（XX は日付）にバイナリ形式で保存する - sa2：1 日分のデータをテキスト形式のサマリーファイル（
/var/log/sa/sarXX）に変換する
収集間隔を変更する場合
障害調査で 10 分間隔では粗すぎる場合、/etc/cron.d/sysstat の sa1 の行を編集して収集間隔を短くできます。ただし、間隔を短くするとデータファイルのサイズが増加するため、ディスク容量とのバランスを考慮してください。
sar -u（CPU リアルタイム）
sar -u は CPU 使用率をリアルタイムで表示します。1 秒間隔で 3 回取得する例を示します。
実行コマンド：
$ sar -u 1 3実行結果：
23時31分17秒 CPU %user %nice %system %iowait %steal %idle
23時31分18秒 all 0.00 0.00 0.50 0.00 0.00 99.50
23時31分19秒 all 0.00 0.00 0.00 0.00 0.00 100.00
23時31分20秒 all 0.00 0.00 0.00 0.00 0.00 100.00
平均値: all 0.00 0.00 0.17 0.00 0.00 99.83各列の意味は以下の通りです。
- %user：ユーザー空間（アプリケーション）の CPU 使用率
- %nice：nice 値で優先度を変更したプロセスの CPU 使用率
- %system：カーネル空間の CPU 使用率
- %iowait：I/O 完了待ちで CPU がアイドル状態の割合。高い場合はディスク I/O がボトルネック
- %steal：仮想環境でホスト側に CPU 時間が奪われた割合
- %idle：CPU が完全にアイドル状態の割合
sar -f（過去データの参照）
障害調査で最も価値があるのは、過去のデータを遡って確認できる点です。/var/log/sa/saXX（XX は日付）を指定することで、任意の日のデータを参照できます。
実行コマンド：
$ sar -f /var/log/sa/sa25このコマンドで 25 日の CPU 使用率を時系列で確認できます。「昨日の夜から遅いと言われている」というような報告に対して、該当時間帯の負荷状況を数値で把握できるため、推測ではなくデータに基づいた障害分析が可能になります。
2. CPU 監視
top -bn1（バッチモード）
top はシステム全体の負荷状況とプロセス一覧をリアルタイムで表示するコマンドです。-bn1 オプションを付けるとバッチモードで 1 回だけ出力するため、スクリプトからの呼び出しやログへのリダイレクトに使えます。
実行コマンド：
$ top -bn1 | head -5実行結果：
top - 23:30:57 up 1 day, 9:02, 0 users, load average: 0.00, 0.00, 0.00
Tasks: 133 total, 2 running, 131 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 3.1 sy, 0.0 ni, 96.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 3911.1 total, 3017.3 free, 553.5 used, 581.9 buff/cache
MiB Swap: 4040.0 total, 4040.0 free, 0.0 used. 3357.6 avail Memヘッダ部分の読み方は以下の通りです。
- load average：1 分 / 5 分 / 15 分のロードアベレージ（実行待ちプロセスの平均数）
- Tasks：プロセスの総数と状態別の内訳。zombie が 0 以外の場合は親プロセスの問題を調査する
- %Cpu(s)：us（ユーザー）、sy（カーネル）、id（アイドル）、wa（I/O 待ち）、st（steal）の割合
- MiB Mem / Swap：物理メモリと Swap の使用状況。avail Mem が実質的に利用可能なメモリ量
top のインタラクティブ操作
top をインタラクティブモード（オプションなしで実行）で使う場合、以下のキー操作で表示を切り替えられます。
| キー | 操作内容 |
|---|---|
| P | CPU 使用率順にソート |
| M | メモリ使用率順にソート |
| 1 | コア別の CPU 使用率を表示 |
| q | top を終了 |
vmstat（CPU・メモリ・I/O の概況）
vmstat は CPU・メモリ・Swap・I/O の概況を 1 行で表示するコマンドです。1 秒間隔で 3 回取得する例を示します。
実行コマンド：
$ vmstat 1 3実行結果：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 3089580 7516 588380 0 0 1 2 20 27 0 0 100 0 0
0 0 0 3089552 7516 588420 0 0 0 0 67 74 0 0 100 0 0
0 0 0 3089552 7516 588420 0 0 0 0 67 64 0 1 99 0 0各列の意味は以下の通りです。
| 列 | 意味 | 注目すべき値 |
|---|---|---|
| r | 実行待ちプロセス数 | コア数を常に超えている場合は CPU 不足 |
| b | I/O 待ちでブロックされているプロセス数 | 1 以上が継続する場合はディスク I/O を調査 |
| si / so | Swap イン / Swap アウト（KB/s） | 継続的に 0 以外ならメモリ不足 |
| us | ユーザー空間 CPU 使用率（%） | アプリケーション負荷の指標 |
| sy | カーネル空間 CPU 使用率（%） | 高い場合はシステムコールの多発を調査 |
| id | アイドル（%） | 低い場合は CPU がボトルネック |
| wa | I/O 待ち（%） | 高い場合はディスク I/O がボトルネック |
| st | steal time（%） | 仮想環境でホストに CPU 時間が奪われた割合 |
vmstat の 1 行目は起動時からの累積値
vmstat の最初の 1 行目は、OS 起動時からの平均値です。リアルタイムの状況を把握するには 2 行目以降を参照してください。
mpstat -P ALL（コア別 CPU 使用率）
マルチコア環境で特定のコアに負荷が偏っていないかを確認するには mpstat を使います。sysstat パッケージに含まれています。
実行コマンド：
$ mpstat -P ALL 1 1特定のコアだけ %usr や %sys が高い場合は、シングルスレッドで動作するプロセスがそのコアに固定されている可能性があります。
ロードアベレージの読み方
ロードアベレージは、実行可能状態または I/O 待ち状態のプロセス数の平均値です。uptime や top の出力に表示される 3 つの数値は、それぞれ 1 分 / 5 分 / 15 分の平均を示しています。
実行コマンド：
$ nprocこのコマンドで論理 CPU 数を確認できます。ロードアベレージの値がこの CPU 数を超えている場合は、プロセスが CPU の割り当てを待っている状態であり、パフォーマンスへの影響を調査する必要があります。
ロードアベレージが高い = CPU 不足とは限らない
ロードアベレージには I/O 待ちのプロセスも含まれます。ロードアベレージが高い場合は、vmstat の wa 列や iostat で I/O 待ちが原因かどうかを切り分けてください。
3. メモリ監視
free -h（メモリ使用状況）
free -h は物理メモリと Swap の使用状況を人間が読みやすい単位で表示します。メモリの余裕を判断するときに最初に実行するコマンドです。
実行コマンド：
$ free -h出力で注目すべきは available 列です。free 列はバッファ/キャッシュに使われていない純粋な空きメモリですが、Linux カーネルはファイルの読み書きを高速化するためにメモリをバッファ/キャッシュとして積極的に利用します。このバッファ/キャッシュは、アプリケーションがメモリを必要としたときにカーネルが自動的に解放します。そのため、実質的に利用可能なメモリ量は free ではなく available で判断してください。
/proc/meminfo の主要フィールド
/proc/meminfo はカーネルが公開するメモリ情報の詳細です。free -h よりも細かい内訳を確認できます。
実行コマンド：
$ cat /proc/meminfo | head -10主要なフィールドの意味は以下の通りです。
| フィールド | 意味 |
|---|---|
| MemTotal | 物理メモリの総量 |
| MemFree | 未使用の物理メモリ |
| MemAvailable | 新しいプロセスが利用可能なメモリ（free -h の available に対応） |
| Buffers | ブロックデバイスの I/O バッファ |
| Cached | ファイルキャッシュ |
| SwapTotal | Swap 領域の総量 |
| SwapFree | 未使用の Swap 領域 |
sar -r（メモリ使用率の推移）
sar -r はメモリ使用率を時系列で記録・表示します。リアルタイムの確認だけでなく、sar -r -f /var/log/sa/saXX で過去のメモリ使用推移も参照できます。
実行コマンド：
$ sar -r 1 3%memused が継続的に 90% を超えている場合や、%swpused が増加傾向にある場合は、メモリ不足を疑い、プロセス単位のメモリ使用量を調査してください。
vmstat -s（メモリ統計サマリー）
vmstat -s はメモリとスケジューリングの累積統計をサマリー形式で表示します。ページイン/ページアウトの回数など、free -h では見えない情報を確認できます。
実行コマンド：
$ vmstat -s4. ディスク I/O 監視
iostat -xz（デバイス別 I/O 詳細）
iostat はデバイス単位のディスク I/O 統計を表示するコマンドです。sysstat パッケージに含まれています。-x で拡張統計、-z でアクティビティのないデバイスを非表示にします。
実行コマンド：
$ iostat -xz 1 2実行結果（先頭部分）：
avg-cpu: %user %nice %system %iowait %steal %idle
0.02 0.00 0.10 0.01 0.00 99.87
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s ... %util
sda 0.07 2.31 0.01 11.94 0.53 31.29 0.11 4.46 ... 0.01iostat の主要列の意味と判断基準は以下の通りです。
| 列 | 意味 | 判断基準 |
|---|---|---|
| r/s, w/s | 1 秒あたりの読み取り/書き込みリクエスト数 | デバイスの性能上限と比較する |
| rkB/s, wkB/s | 1 秒あたりの読み取り/書き込みデータ量（KB） | 帯域幅の使用状況を把握する |
| r_await, w_await | 読み取り/書き込みリクエストの平均待ち時間（ms） | HDD で 20ms 以上、SSD で 5ms 以上は要調査 |
| await | I/O リクエスト全体の平均待ち時間（ms） | 高い場合は I/O ボトルネック |
| %util | デバイスが I/O 処理を行っていた時間の割合 | 100% に近い場合はデバイスが飽和状態 |
await が高い = I/O ボトルネック
await の値が継続的に高い場合、ディスクがリクエストを処理しきれていない状態です。%util が 100% に近い場合はデバイスが飽和しており、ディスクの追加や I/O パターンの見直しが必要です。
sar -d（ディスク I/O 推移）
sar -d はディスク I/O の推移を時系列で記録・表示します。過去データの参照は sar -d -f /var/log/sa/saXX で行います。
実行コマンド：
$ sar -d 1 3df -i（inode 枯渇チェック）
ディスク容量に余裕があっても、inode が枯渇するとファイルを新規作成できなくなります。小さなファイルを大量に生成するアプリケーション（メールキュー、セッションファイルなど）では inode の監視も必要です。
実行コマンド：
$ df -iIUse% が 100% に達すると、ディスク容量が残っていてもファイル作成が失敗します。
5. プロセス調査と制御
ps aux –sort（プロセスのソート表示）
リソースを多く消費しているプロセスを特定するには、ps aux を使用率順でソートします。
メモリ消費順に上位 10 件を表示する実行コマンド：
$ ps aux --sort=-%mem | head -10実行結果：
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 761 0.0 1.2 360520 50244 ? Ssl 3月24 0:03 /usr/bin/python3 -s /usr/sbin/firewalld
polkitd 847 0.0 0.6 2579964 26416 ? Ssl 3月24 0:00 /usr/lib/polkit-1/polkitd
root 772 0.0 0.5 259460 21504 ? Ssl 3月24 0:10 /usr/sbin/NetworkManagerCPU 消費順に上位 10 件を表示する実行コマンド：
$ ps aux --sort=-%cpu | head -10出力の主要列は以下の通りです。
- %CPU：プロセスの CPU 使用率
- %MEM：プロセスの物理メモリ使用率
- VSZ：仮想メモリサイズ（KB）。ライブラリの共有領域を含むため、実際の消費量より大きく見える
- RSS：常駐メモリサイズ（KB）。プロセスが実際に使用している物理メモリ量
pidstat（プロセス単位のリソース監視）
pidstat は sysstat パッケージに含まれるコマンドで、プロセス単位の CPU・メモリ・ディスク I/O を継続的に監視できます。
プロセス単位の CPU 使用率を 1 秒間隔で表示する実行コマンド：
$ pidstat -u 1プロセス単位のメモリ使用量を 1 秒間隔で表示する実行コマンド：
$ pidstat -r 1プロセス単位のディスク I/O を 1 秒間隔で表示する実行コマンド：
$ pidstat -d 1top では全プロセスの一覧しか見えませんが、pidstat を使うと特定プロセスのリソース消費を時系列で追跡できます。
kill（プロセスの停止）
暴走プロセスを停止する場合は、まず SIGTERM（シグナル番号 15）を送信します。SIGTERM はプロセスに終了処理の猶予を与えるシグナルです。プロセスが SIGTERM で停止しない場合に限り、SIGKILL（シグナル番号 9）を使います。SIGKILL はプロセスを即座に強制終了するため、データの書き込み途中で中断される可能性があります。
実行コマンド（SIGTERM）：
$ kill 実行コマンド（SIGKILL。SIGTERM で停止しない場合のみ）：
$ kill -9 いきなり kill -9 を使わない
SIGKILL はプロセスにクリーンアップの機会を与えません。データベースプロセスに対して kill -9 を実行すると、トランザクションログの破損やデータ不整合が発生する可能性があります。必ず SIGTERM → 数秒待機 → SIGKILL の順序で対応してください。
nice / renice（優先度制御）
nice 値はプロセスの CPU スケジューリング優先度を制御する値で、-20（最高優先度）から 19（最低優先度）の範囲です。バッチ処理など優先度の低いプロセスに高い nice 値を設定することで、他のプロセスへの影響を抑えられます。
nice 値 10 でプロセスを起動する実行コマンド：
$ nice -n 10 <コマンド>実行中のプロセスの nice 値を変更する実行コマンド：
# renice -n 10 -p 一般ユーザーは nice 値を上げる（優先度を下げる）ことのみ可能です。nice 値を下げる（優先度を上げる）には root 権限が必要です。
6. ネットワーク概況（パフォーマンス観点）
ここではパフォーマンス監視の観点から、コネクション数とトラフィック量を確認するコマンドを紹介します。詳細なネットワーク診断（traceroute、dig 等）については、ネットワーク設定編（第3回）を参照してください。
ss -s（コネクション数サマリー）
ss -s は TCP/UDP のコネクション数をサマリー形式で表示します。コネクション数の急増は、アプリケーションのコネクションリークや DDoS 攻撃の兆候である場合があります。
実行コマンド：
$ ss -s実行結果：
Total: 118
TCP: 8 (estab 1, closed 5, orphaned 0, timewait 5)timewait が大量に蓄積されている場合は、短寿命の TCP コネクションが頻繁に作成・切断されていることを示します。
ss -tlnp（リッスンポート一覧）
ss -tlnp はリッスン状態の TCP ポートと、そのポートを使用しているプロセスを表示します。想定外のポートがリッスンしていないかの確認に使います。
実行コマンド：
$ ss -tlnp実行結果：
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*sar -n DEV（NIC 別トラフィック量）
sar -n DEV は NIC（ネットワークインターフェース）ごとのトラフィック量を表示します。帯域幅の使用状況を把握し、ネットワークがボトルネックになっていないかを確認します。
実行コマンド：
$ sar -n DEV 1 3rxkB/s（受信）と txkB/s（送信）がNIC の物理帯域幅に近い値を示している場合は、ネットワーク帯域がボトルネックです。
7. tuned プロファイル
tuned は、サーバーの用途に応じてカーネルパラメータや電源管理設定を一括で最適化するデーモンです。プロファイルを切り替えるだけで、CPU ガバナーや I/O スケジューラ、ネットワーク設定などが用途に合わせて調整されます。
現在のプロファイル確認
実行コマンド：
$ tuned-adm active実行結果：
Current active profile: virtual-guest推奨プロファイルの確認
tuned-adm recommend は、ハードウェア構成や仮想化環境を自動検出し、推奨プロファイルを提示します。
実行コマンド：
$ tuned-adm recommend実行結果：
virtual-guestこの環境は Hyper-V 仮想マシンのため、virtual-guest が推奨されています。
利用可能なプロファイル一覧
実行コマンド：
$ tuned-adm list主要プロファイルの用途
| プロファイル | 用途 |
|---|---|
| balanced | パフォーマンスと省電力のバランス（デフォルト） |
| throughput-performance | スループット重視。バッチ処理やファイルサーバー向け |
| latency-performance | レイテンシ重視。データベースサーバーや Web サーバー向け |
| virtual-guest | 仮想マシンのゲスト OS 向け |
| virtual-host | 仮想化ホスト（ハイパーバイザー）向け |
プロファイルの切り替え
プロファイルの変更は即座に反映され、OS を再起動しても維持されます。
実行コマンド：
# tuned-adm profile throughput-performanceプロファイル選定の考え方
仮想マシンでは tuned-adm recommend の推奨に従うのが基本です。物理サーバーでは、サーバーの主な用途（Web / DB / バッチ）に応じてプロファイルを選定してください。判断に迷った場合は balanced のまま運用し、パフォーマンス問題が発生した時点で切り替えを検討する方法が安全です。
8. OOM Killer
OOM Killer（Out of Memory Killer）は、Linux カーネルがメモリ枯渇を検知したときに、プロセスを強制終了してシステム全体のクラッシュを防ぐ仕組みです。OOM Killer は「犯人」ではなく「最後の安全弁」であり、根本原因はメモリリークやサーバーのサイジング不足にあります。
OOM Killer の発動履歴確認
OOM Killer が発動した場合、カーネルログに記録されます。以下のコマンドで確認できます。
実行コマンド：
$ journalctl -k --grep="Out of memory"dmesg でも確認できます。
実行コマンド：
$ dmesg | grep -i oomoom_score と oom_score_adj
カーネルは各プロセスに oom_score（0〜1000 程度）を算出し、OOM Killer 発動時にスコアが最も高いプロセスを終了対象に選びます。
特定プロセスの OOM スコアを確認する実行コマンド：
$ cat /proc//oom_score oom_score_adj はスコアの調整値で、-1000 から 1000 の範囲で設定できます。-1000 を設定すると OOM Killer の対象外となります。データベースなどの重要プロセスを保護する場合に使用します。
実行コマンド：
# echo -1000 > /proc//oom_score_adj oom_score_adj は恒久対策ではない
oom_score_adj でプロセスを保護しても、メモリ不足の根本原因は解消されません。別のプロセスが OOM Killer に選ばれるだけです。メモリリークの修正やメモリ増設など、根本的な対処を並行して進めてください。
メモリオーバーコミットと Swappiness
カーネルのメモリ管理に関する 2 つの重要なパラメータを確認します。
実行コマンド：
$ cat /proc/sys/vm/overcommit_memory実行結果：
0実行コマンド：
$ cat /proc/sys/vm/swappiness実行結果：
60| パラメータ | 値 | 意味 |
|---|---|---|
| vm.overcommit_memory | 0 | ヒューリスティック判定。物理メモリ + Swap を超える可能性がある場合でも、カーネルが判断して許可する（デフォルト） |
| vm.overcommit_memory | 1 | 常に許可。malloc が失敗しないが、OOM Killer が発動しやすくなる |
| vm.overcommit_memory | 2 | 制限モード。物理メモリ + Swap の一定割合を超える割り当てを拒否する |
| vm.swappiness | 60 | Swap の使用積極度（0〜100）。値が大きいほど Swap を積極的に使う。デフォルトは 60 |
9. 物理サーバー固有の監視
仮想サーバーの場合
仮想サーバーでは温度・ファン・電圧などのハードウェア監視はハイパーバイザー側の責務です。ゲスト OS からこれらのセンサー情報にアクセスする必要はありません。この章は物理サーバーを運用する場合に参照してください。
ipmitool（ハードウェアセンサー監視）
ipmitool は IPMI（Intelligent Platform Management Interface）経由でサーバーのハードウェアセンサーを読み取るコマンドです。CPU 温度、ファン回転数、電圧などを確認できます。
センサー一覧を表示する実行コマンド：
# ipmitool sensor list全センサーデータを表示する実行コマンド：
# ipmitool sdr listシステムイベントログを表示する実行コマンド：
# ipmitool sel listipmitool sel list は、ハードウェアレベルのイベント（温度異常、ファン故障、電源障害など）の履歴を確認するのに使います。
smartctl（ディスク故障予兆の検知）
smartctl は S.M.A.R.T.（Self-Monitoring, Analysis and Reporting Technology）情報を読み取るコマンドで、ディスクの故障予兆を検知します。smartmontools パッケージに含まれています。
実行コマンド：
# smartctl -a /dev/sdXReallocated_Sector_Ct（代替セクタ数）や Current_Pending_Sector（保留中のセクタ数）が増加傾向にある場合は、ディスク交換を計画してください。
サーマルスロットリング
サーマルスロットリングは、CPU 温度が上限に達したときにクロック周波数を自動的に低下させる保護機能です。データセンターの空調障害やサーバー内部のエアフロー不良が原因で発生します。パフォーマンスが突然低下した場合、ipmitool で CPU 温度を確認し、温度が異常に高ければ物理的な対処（空調点検、ファン交換など）が必要です。
物理サーバーがない検証環境では実行不可
ipmitool や smartctl は物理ハードウェアにアクセスするコマンドです。仮想マシンや検証環境では実行してもエラーになるか、意味のある情報が得られません。出力例はベンダーやハードウェアモデルによって異なります。
10. 仮想サーバー固有の監視
物理サーバーの場合
物理サーバーでは steal time は発生しません。%steal が常に 0 であるのは正常です。この章は仮想サーバーを運用する場合に参照してください。
%steal（CPU 時間の横取り）
%steal は、仮想マシンのゲスト OS が CPU 時間を要求したにもかかわらず、ホスト側の過負荷によって割り当てられなかった時間の割合です。sar -u の %steal 列、vmstat の st 列、top の st で確認できます。
%steal が継続的に 5% を超えるような場合は、ホスト側の CPU リソースが不足しています。ゲスト OS 側では対処できないため、ホスト管理者（仮想化基盤の運用チーム）にエスカレーションし、リソースの再配分や仮想マシンの移行を依頼してください。
virtio_balloon（メモリバルーニング）
virtio_balloon は、ホスト側からゲストのメモリを動的に回収・返却する仕組みです。ホストのメモリが不足した場合に、ゲストからメモリが回収される可能性があります。
virtio_balloon ドライバがロードされているかの確認コマンド：
$ lsmod | grep virtio_balloonこのドライバがロードされている環境では、free -h で表示されるメモリ量が動的に変動する場合があります。
systemd-detect-virt（仮想化種類の確認）
現在の仮想化環境の種類を確認するコマンドです。
実行コマンド：
$ systemd-detect-virt実行結果：
microsoftこの結果は Hyper-V 環境であることを示しています。KVM 環境では kvm、VMware では vmware と表示されます。物理サーバーでは none が返ります。
cgroup v2 によるリソース制限の確認
AlmaLinux 9 では cgroup v2 がデフォルトで有効です。コンテナ環境や systemd のリソース制限で、プロセスに対するメモリや CPU の上限が設定されている場合があります。
メモリ上限の確認コマンド：
$ cat /sys/fs/cgroup/memory.maxmax と表示された場合は制限なし、数値が表示された場合はバイト単位でのメモリ上限が設定されています。パフォーマンス問題の調査時に、cgroup による制限がボトルネックになっていないかを確認してください。
11. 障害時の初動フロー
「サーバーが遅い」と報告されたときの調査手順をチートシートとしてまとめます。上から順に実行し、ボトルネックを切り分けてください。
| 順序 | コマンド | 確認する内容 |
|---|---|---|
| 1 | uptime | ロードアベレージで負荷の全体感を把握する |
| 2 | top / vmstat 1 3 | CPU・メモリ・I/O の概況をリアルタイムで確認する |
| 3 | iostat -xz 1 | ディスク I/O にボトルネックがないかを確認する |
| 4 | free -h | メモリ枯渇や Swap の使用状況を確認する |
| 5 | ps aux –sort=-%cpu | CPU を大量に消費しているプロセスを特定する |
| 6 | sar -f /var/log/sa/saXX | 過去データと比較し、負荷が上昇した時間帯を特定する |
| 7 | journalctl -k | カーネルエラーや OOM Killer の発動履歴を確認する |
sar の過去データがない場合
sysstat が導入されていない環境では sar の過去データが存在しません。障害が発生してから sysstat を導入しても、過去のデータは取得できません。新規サーバー構築時に sysstat を導入しておくことが、将来の障害調査を大きく助けます。
12. トラブルシューティング
ロードアベレージが高いが原因が分からない
ロードアベレージが高い場合、まず top で %Cpu(s) の wa（I/O wait）を確認してください。wa が高い場合はディスク I/O がボトルネックであり、iostat -xz 1 でデバイス別の I/O 状況を調査します。wa が低く us や sy が高い場合は CPU がボトルネックであり、ps aux –sort=-%cpu で原因プロセスを特定します。
メモリが足りないのに free が少ない
free -h の free 列が少なくても、それだけではメモリ不足とは判断できません。Linux カーネルは空きメモリをバッファ/キャッシュとして積極的に利用するため、free が少ないのは正常な動作です。available 列を確認し、この値が少ない場合に初めてメモリ不足と判断してください。
OOM Killer でプロセスが強制終了された
journalctl -k --grep="Out of memory" で OOM Killer の発動を確認します。どのプロセスが終了されたかはログに記録されています。データベースなどの重要プロセスが OOM Killer の対象になるのを防ぐには、/proc/<PID>/oom_score_adj に -1000 を設定します。ただし、これは一時的な保護であり、根本原因（メモリリーク、サイジング不足）の対処が必要です。
iostat の %util が常に 100%
%util が常に 100% に近い場合、そのデバイスは I/O リクエストの処理能力の限界に達しています。対処方法としては、LVM でディスクを追加して I/O を分散する、I/O スケジューラを変更する（cat /sys/block/sdX/queue/scheduler で現在のスケジューラを確認）、SSD への換装を検討する、などがあります。
仮想環境で %steal が高い
%steal が高い場合、ホスト側の CPU が過負荷状態であり、ゲスト OS に十分な CPU 時間が割り当てられていません。ゲスト OS 側でのチューニングでは解決できないため、ホスト管理者に以下の対応を依頼してください。
- 仮想マシンを別のホストに移行する
- ホスト上の他の仮想マシンの CPU リソースを調整する
- ホストの CPU リソースを増強する
