はじめに
本記事は性能試験中にシステムの遅延や応答時間の劣化が発生した場合に、4つのツール「jstat」「mpstat」「vmstat」「sar」を、どう使い分けるか解説します。
※補足
Javaアプリケーションを例にしていますが、mpstat、vmstat、sarはLinuxサーバ全般で有効なツールです。PythonやNode.js、Go、Ruby、DBサーバ、Nginxなど他のアプリケーションやサービスでも、CPU・メモリ・I/O負荷やリソース状況の分析方法は同様です。
たとえば「CPUの偏り」「スワップ発生」「I/O待ち」などの現象はアプリ種別を問わず発生します。各ツールの見方・分析手順は汎用的なので、JVM以外の運用でも同じ流れで活用できます。アプリ固有の内部要因分析（JVMならjstat、DBなら各種statコマンド等）以外は、ほぼ共通です。
各ツールの役割と主な使用法
- jstat
JVMのヒープ使用状況やGCの頻度を把握。Javaアプリケーション特有のメモリ問題の特定に役立ちます。
使用例：jstat -gcutil <プロセスID> 1000
- mpstat
CPU全体およびコア単位の使用率を確認し、負荷の偏りや割り込みの影響を分析します。
使用例：mpstat -P ALL 1 - vmstat
メモリ、スワップ、プロセス、ブロックI/Oなど、システム全体の状態をリアルタイムで把握します。
使用例：vmstat 1 - sar
長期間の時系列データを蓄積し、負荷の変動や異常発生タイミングを詳細に分析できます。使用例：sar -u 1
複合的分析の具体的な手順
これらのツールを組み合わせた分析手順を詳しく解説します。
-
sarで異常発生時刻を特定
sar -uやsar -dコマンドで、CPU使用率やI/O待ち時間のピークを確認します。異常が起きた具体的な時間帯を特定します。
-
mpstatでCPUの挙動を深掘り
mpstat -P ALLで、各CPUコアごとの使用率をチェック。特定のコアに負荷が集中しているか、割り込み（IRQ）が多発しているかを調べます。
-
vmstatでシステムリソースの状態を総合的に確認
vmstatで、メモリ不足（freeメモリ量）、スワッピング状況（si, soの値）、I/O状況（bi, boの値）を確認します。
-
jstatでJVM内部の問題を追跡
実践例：Java Webアプリケーションのレスポンス遅延を分析
ここでは、Javaで構築されたWebアプリケーションサーバーで、15:00頃からレスポンス遅延が発生したケースを例にします。
sarで異常発生時刻を特定
sar -u 1 5出力例：
15:00:00 all 10.25 0.00 2.13 1.37 0.00 86.25
15:00:01 all 12.17 0.00 3.10 2.20 0.00 82.53
15:00:02 all 40.00 0.00 15.00 5.00 0.00 40.00
15:00:03 all 38.50 0.00 14.75 6.25 0.00 40.50
15:00:04 all 35.80 0.00 12.20 5.10 0.00 46.90→ 15:00:02以降、CPU使用率が40%まで急増。ここから問題が始まったと判断。
mpstatでコアごとの負荷分散を確認
mpstat -P ALL 1 5出力例：
15:00:01 0 90.00 0.00 10.00 0.00 0.00 0.00 0.00 0.00 0.00
15:00:01 1 8.00 0.00 2.00 1.00 0.00 0.00 0.00 0.00 89.00
15:00:02 0 88.50 0.00 11.00 0.00 0.00 0.00 0.00 0.00 0.50
15:00:02 1 9.10 0.00 2.20 1.10 0.00 0.00 0.00 0.00 87.60
15:00:03 0 91.20 0.00 8.50 0.00 0.00 0.00 0.00 0.00 0.30→ CPUコア0が90%以上で高負荷。特定コアへの処理集中が見られる。
vmstatでメモリ・I/O状況を把握
vmstat 1 5出力例：
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 204800 491520 204800 409600 64 32 100 50 100 200 30 5 60 5 0
1 0 204800 480000 205000 410000 60 30 90 45 98 210 31 4 60 5 0
1 1 204800 470000 206000 420000 62 31 95 55 102 205 32 5 59 4 0
2 0 204800 460000 207000 430000 63 33 97 48 101 208 30 5 61 4 0
1 0 204800 455000 208000 440000 61 29 92 52 99 199 29 4 62 5 0→ so（swap out）が多発。freeメモリが減少しており、物理メモリ不足でスワップが発生している。
jstatでJVMヒープ・GC頻度を分析
jstat -gcutil <PID> 1000 5出力例：
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
2.00 0.00 90.00 95.00 95.50 89.00 80 12.10 5 5.98 18.08
3.10 0.00 91.50 96.00 95.70 90.00 82 13.00 6 6.35 19.35
2.80 0.00 92.00 96.80 96.10 90.20 85 14.20 7 7.21 21.41
3.00 0.00 92.50 97.50 96.30 90.50 87 15.00 8 7.95 22.95
3.20 0.00 93.00 98.00 96.50 90.80 90 15.80 9 8.30 24.10→ Old領域（O列）が95%以上、Full GC（FGC）が短期間で連発。JVMヒープ逼迫によるGC多発でアプリ遅延と特定。
問題への具体的な対処方法
- JVMヒープサイズの最適化（Old領域を特に増加させる）
- 負荷分散を目的としたスレッド数やスレッドプールの調整
- 物理メモリの増強またはスワップ領域の適切な調整
- GCログの定期取得と分析によるメモリリークの早期検出・対応
まとめ
jstat、mpstat、vmstat、sarを適切に組み合わせることで、「異常発生時刻」「影響範囲」「根本原因」を明確にし、迅速で効果的な性能問題への対処が可能になります。
特にJavaアプリケーションでは、JVMヒープやGCの観点からの分析が不可欠です。
また、mpstat/vmstat/sarの活用法は、アプリ種別を問わずLinux運用現場で幅広く役立ちます。
日々ログを分析し、問題の兆候を早期に発見できる体制を整えることで、システムの信頼性向上につながります。
参考資料
いくつかのキーワードにはてなブログ タグの参照を使用。
コメント