サーバー種別と収集方針

Webシステムは一般的に Web サーバー・APL サーバー・DB サーバー の 3 層構成で動作します。各層でボトルネックになるリソースが異なるため、コマンドのオプションや注目すべき指標も変わります。

サーバー 主な役割 最重要リソース
WebWebサーバー HTTP 受付・静的コンテンツ配信・リバースプロキシ CPU（SSL処理・同時接続）
APLAPLサーバー ビジネスロジック処理・DBアクセス CPU・メモリ（GC・ヒープ）
DBDBサーバー データの永続化・クエリ処理 ディスク I/O・メモリ（バッファプール）

収集の基本方針：テスト中は全サーバーで 5 秒間隔・継続収集。負荷が発生している時刻に各サーバーで何が起きていたかを時刻軸で突き合わせるのが目的です（NTP 同期前提）。

mpstat コマンド

mpstat は CPU 使用率をコアごとに詳細に表示します。%idle の低下・%iowait の上昇を監視します。

WebWebサーバー

SSL ターミネーションや大量同時接続による CPU 圧迫を確認します。%usr が継続的に高い場合は CPU バウンドを疑います。

# 全コア・5秒間隔・12回（計1分）
mpstat -P ALL 5 12

# ファイルに保存する場合
mpstat -P ALL 5 12 >> /tmp/mpstat_web.txt
列 注目ポイント（Webサーバー）
%usr SSL 処理・静的コンテンツ圧縮で上昇。継続的に高い場合は SSL オフロードを検討
%idle 20% 以上を目安に確保。10% 未満が続く場合は要対策

APLAPLサーバー

ビジネスロジックの計算量・スレッド競合による CPU 使用を確認します。コアごとの偏りにも注意が必要です。

# 全コア・5秒間隔・12回
mpstat -P ALL 5 12

# コアごとの偏りを確認したい場合（コア番号を指定）
mpstat -P 0,1,2,3 5 12

# ファイルに保存する場合
mpstat -P ALL 5 12 >> /tmp/mpstat_apl.txt
列 注目ポイント（APLサーバー）
%usr アプリ処理・GC で上昇。GC ログと照合して原因を切り分ける
%iowait 高い場合は APL ではなく DB の I/O 待ちが原因の可能性大
%idle 20% 以上を目安に確保

DBDBサーバー

クエリ処理・ソート・ハッシュ結合による CPU 使用を確認します。CPU が低くても %iowait が高い場合はディスク I/O がボトルネックです。

# 全コア・5秒間隔・12回
mpstat -P ALL 5 12

# ファイルに保存する場合
mpstat -P ALL 5 12 >> /tmp/mpstat_db.txt
列 注目ポイント（DBサーバー）
%iowait 最重要。10% 超えたら要注意。フルスキャン・バッファプール不足の疑い
%usr クエリ処理・ソート処理で上昇。スロークエリログと照合
%idle CPU は余っているのに遅い → I/O 待ちまたはロック競合

free コマンド

free はメモリ・スワップの使用状況を表示します。「free」列ではなく「available」列を基準に判断します。

WebWebサーバー

静的ファイルのキャッシュに buff/cache が活用されます。スワップが増加している場合は同時接続数や Worker 数の設定を見直します。

# 1回だけ表示（単位: MB）
free -m

# 5秒間隔で繰り返す場合
while true; do
  echo "=== $(date '+%H:%M:%S') ===" >> /tmp/free_web.txt
  free -m >> /tmp/free_web.txt
  sleep 5
done
列 注目ポイント（Webサーバー）
available 実質的に使用できる空きメモリ。全体の 20% 以上を目安に確保
Swap used 増加傾向が見られたら Worker プロセス数・接続数の設定を確認

APLAPLサーバー

Java などの JVM 言語では GC が多発するとメモリが一時的に増減します。スワップが発生するとレスポンスタイムが大きく悪化します。

# 1回だけ表示（単位: MB）
free -m

# 5秒間隔で繰り返す場合
while true; do
  echo "=== $(date '+%H:%M:%S') ===" >> /tmp/free_apl.txt
  free -m >> /tmp/free_apl.txt
  sleep 5
done

# JVM ヒープ使用量と合わせて確認（Java アプリの場合）
jstat -gc $(pgrep -f java | head -1) 5000
列 注目ポイント（APLサーバー）
available テスト進行とともに減少していないか確認。減少が続く場合はメモリリークを疑う
Swap used 最重要。スワップが発生するとレスポンスタイムが大幅悪化。ヒープサイズ設定を見直す

DBDBサーバー

DB サーバーはバッファプール（InnoDB buffer pool / Oracle SGA など）がメモリを大量消費します。バッファプールが縮小されるとディスク I/O が増加します。

# 1回だけ表示（単位: MB）
free -m

# 5秒間隔で繰り返す場合
while true; do
  echo "=== $(date '+%H:%M:%S') ===" >> /tmp/free_db.txt
  free -m >> /tmp/free_db.txt
  sleep 5
done
列 注目ポイント（DBサーバー）
available バッファプールが十分確保されているか確認。ディスク I/O 増加と合わせて判断
buff/cache DB のバッファプールが大半を占める。この値が突然減少した場合は DB 設定を確認
Swap used スワップ発生は致命的。バッファプールサイズの見直しが必要

iostat コマンド

iostat はディスクデバイスごとの I/O 統計を表示します。%util と await が主要な監視指標です。

WebWebサーバー

静的コンテンツ配信・ログ書き込みが主な I/O です。通常は I/O 負荷は低めですが、大量ログが発生している場合は確認が必要です。

# 拡張統計・5秒間隔・12回
iostat -xz 5 12

# ファイルに保存する場合
iostat -xz 5 12 >> /tmp/iostat_web.txt
列 注目ポイント（Webサーバー）
%util 通常は低い（20% 未満）。高い場合はログローテーション設定・出力先を確認
w/s アクセスログの書き込み頻度。非常に高い場合はログバッファリング設定を確認

APLAPLサーバー

アプリログ・一時ファイル書き込みが主な I/O です。%iowait（mpstat）が高くても iostat の %util が低い場合は DB 待ちの可能性があります。

# 拡張統計・5秒間隔・12回
iostat -xz 5 12

# デバイス名を指定して確認（例: sda）
iostat -xz -d sda 5 12

# ファイルに保存する場合
iostat -xz 5 12 >> /tmp/iostat_apl.txt
列 注目ポイント（APLサーバー）
%util 低い（20% 未満）が正常。高い場合は一時ファイル・アプリログ出力量を確認
await 10ms 以内が目安。超える場合はディスク自体の問題を疑う

DBDBサーバー

ディスク I/O が最も重要なのは DB サーバーです。フルスキャン・バッファプール不足・大量書き込みが %util と await に直結します。

# 拡張統計・5秒間隔・12回
iostat -xz 5 12

# 読み書きの内訳を詳細確認したい場合
iostat -xz -p ALL 5 12

# ファイルに保存する場合
iostat -xz 5 12 >> /tmp/iostat_db.txt
列 注目ポイント（DBサーバー）
%util 最重要。80% 超で要注意・90% 超は危険。インデックス追加・バッファプール増量を検討
await 最重要。10ms 超で注意・20ms 超は危険。SSD 化・RAID 見直しを検討
rkB/s フルスキャンで急増。スロークエリログと照合してインデックス不足を確認
wkB/s 大量 INSERT/UPDATE・ログフラッシュで増加

vmstat コマンド

vmstat は CPU・メモリ・スワップ・I/O をまとめて確認できるシステム全体の概観コマンドです。最初の 1 行は起動からの累計値のため分析対象外です。

WebWebサーバー

同時接続が増えた際の CPU プロセスキュー（r）と I/O ブロック数（b）を確認します。

# 5秒間隔・12回（2行目以降を分析）
vmstat 5 12

# ファイルに保存する場合
vmstat 5 12 >> /tmp/vmstat_web.txt
列 注目ポイント（Webサーバー）
r 実行待ちプロセス数。CPU コア数を超え続ける場合は CPU ボトルネック
b I/O 待ちブロック数。通常はほぼ 0。増加する場合はログ書き込みを確認
si / so スワップイン/アウト。0 が正常。継続的に値があればメモリ不足

APLAPLサーバー

スレッドプール枯渇時に r が増加します。GC に伴うメモリ変動も free 列で確認できます。

# 5秒間隔・12回
vmstat 5 12

# メモリ詳細も確認したい場合
vmstat -s

# ファイルに保存する場合
vmstat 5 12 >> /tmp/vmstat_apl.txt
列 注目ポイント（APLサーバー）
r スレッドプール枯渇・キュー詰まりで増加。スレッド数の設定と合わせて確認
free GC 後に一時増加する。継続的に減少する場合はメモリリークの疑い
si / so スワップが発生するとレスポンス悪化。JVM ヒープサイズを見直す
wa 高い場合は DB の I/O 待ちが APL に影響している可能性

DBDBサーバー

DB サーバーでは b（I/O 待ちブロック）・wa（CPU の I/O 待ち割合）・bi/bo（ブロック読み書き量）を重点的に確認します。

# 5秒間隔・12回
vmstat 5 12

# ディスク統計も同時に確認したい場合
vmstat -d 5 12

# ファイルに保存する場合
vmstat 5 12 >> /tmp/vmstat_db.txt
列 注目ポイント（DBサーバー）
b 最重要。I/O 待ちブロック数。0 超えが続く場合はディスクが飽和
wa 最重要。20% 超で要注意。iostat の %util・await と合わせて判断
bi ブロック読み込み量。フルスキャン時に急増
bo ブロック書き込み量。大量 INSERT/UPDATE・redo ログ書き込みで増加
si / so スワップが発生するとバッファプールが圧迫。致命的な性能劣化につながる

まとめ：コマンド一覧表

各サーバーで実行するコマンドと最優先の確認指標を一覧にまとめます。

コマンド サーバー コマンド例 最優先指標
mpstat Web mpstat -P ALL 5 12 %usr, %idle
APL mpstat -P ALL 5 12 %usr, %iowait, %idle
DB mpstat -P ALL 5 12 %iowait, %usr, %idle
free Web free -m (ループ収集) available, Swap used
APL free -m (ループ収集) available, Swap used
DB free -m (ループ収集) available, buff/cache, Swap used
iostat Web iostat -xz 5 12 %util, w/s
APL iostat -xz 5 12 %util, await
DB iostat -xz 5 12 %util, await, rkB/s, wkB/s
vmstat Web vmstat 5 12 r, b, si/so
APL vmstat 5 12 r, free, si/so, wa
DB vmstat 5 12 b, wa, bi, bo, si/so