2017/1/17 JPOUG in 15 minutes #3にて発表した内容です。 昨今、システムの大規模(集約)化がトレンドとなっています。そのようなミッションクリティカルシステムにおいて、いかにして性能問題調査を行っていくかを解説します。

1. 「Oracle Database + Java + Linux」
環境における性能問題の調査手法
～ミッションクリティカルシステムの現場から～
Part. 1
若山 勝吾
2017. 01. 17
© Shogo Wakayama

2. はじめに
昨今、システムの大規模(集約)化がトレンドとなって
います。そのようなミッションクリティカルシステム
において、いかにして性能問題調査を行っていくかを
解説します。
2
仮想化
クラウド化
マルチテナント
大規模
(集約)化
スケールアウト構成
情報量の爆増
24時間無停止
かさむ保守
・運用費
既存システム
のHW老朽化
予測困難な突発的
トラフィック
被災時対策
製品サポート
期間の終了
サービス連携
の多様化
ログ蓄積
の限界
設備設置
スペース不足
迅速なAP開発要件
複数システムをとりまく課題の例
新たなシステム構成
パッチ最新化

3. 自己紹介: 若山 勝吾
• ミッションクリティカルシステム専門
性能改善エンジニア
⇒ 性能試験と性能問題解決が得意です。
• 10年間、性能プロフェッショナルチームに所属
(50を超えるプロジェクトで実績を積む)
• Javaプロファイラ、性能モニタリングツール、
負荷生成ツールの開発・導入支援を経験
3

4. アジェンダ
• ミッションクリティカルシステムにおける性能問題
の考え方
• 性能問題の調査手法の解説
4

5. • ミッションクリティカルシステムにおける性能問題
の考え方
• 性能問題の調査手法の解説
5
－戦略編－

6. ミッションクリティカルシステムにおける
性能問題とは？
• 性能に起因するサービス影響のこと。
• 処理遅延は性能問題である。
6
処理遅延
許容範囲を超過
スループット
低下
リソース
使用率が高
燃費として
は悪い
処理遅延
する寸前
処理遅延すると
スループットも低下
リソース限界時は
応答時間が遅延
対象の業務量が
少ないだけかも
性能問題

7. 7
外的調査
• 遅延範囲(サービス影響)を把握し、
• 応急処置案を見極める。
内的調査
• 被疑箇所の詳細を分析し、
• 遅延原因を解明する。
24x7ミッションクリティカルシステムにおいては、
専門家/有識者がいなくても迅速対応できることが
求められる。
ミッションクリティカルシステムにおける
性能問題の調査とは？

8. クライアント側 サーバ側
本番環境で処理遅延が発生！
①あなたなら、どこから調査しますか？
8
遅い！
遅い！
遅い！
遅い！
Web/APサーバ
(WebLogic)
DBサーバ
(OracleDB)
小規模であれば、得意なレイヤから調査するのもアリ。
(処理種別・ノードが少なければ消去法作戦が可能)
FW/LB
サーバ側で
遅いな
調査対応者
ユーザ
SW
性能問題の所在
説明をシンプルにするため、
サーバ側に問題がある状況
としています。
WAN

9. 9
WAN
DBサーバ
(OracleDB)
本番環境で処理遅延が発生！
②あなたなら、どこから調査しますか？
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
大規模であれば、調査の仕組み化が必要不可欠。
(仕組みが無いと、高度な専門知識があっても苦戦)
FW/LB
Web/APサーバ
(WebLogic)
調査対応者
クライアント側
ユーザ
SW
バッチ系
OLTP系 業務DB
ユーザ
管理DB
サーバ側で
遅いな
性能問題の所在
調査対象が
多くて大変！
サーバ側
説明をシンプルにするため、
サーバ側に問題がある状況
としています。

10. 10
WAN
処理遅延が発生！
③調査完了するまで、状況を放置して大丈夫？
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
遅い！
ミッションクリティカルシステムでは、サービス継続
を優先することが重要。(原因解明は後回しでよい)
もう我慢
限界！！
クライアント側
ユーザ DBサーバ
(OracleDB)
FW/LB
Web/APサーバ
(WebLogic)
調査対応者
SW
バッチ系
OLTP系 業務DB
ユーザ
管理DB
性能問題の所在
一体何が
原因だろう…
見落としは
ないよな…
サーバ側

11. • 応急処置案の見極め
• 流量制御、被疑ノードの切り離し
• 各種分析ツールで情報採取
• CPU時間と待機時間の分析
1. 性能問題発生
2. 遅延範囲の確認
3. 応急処置 ※可能な場合
4. 被疑箇所の詳細分析
5. 遅延原因の解明
6. 改善対処(治療)
7. 経過観察
11
8. 解決
• 性能問題の所在(サーバ側かどうか)の特定
• 処理(機能/API)種別の特定
• 被疑ノードの特定
• 仮説と立証
• サポート問合せ
• 暫定対処(最早解) と 本格対処(最適解)
• 改善効果の評価
• 予兆監視
主なタスク
• 発生条件の特定
• 遅延メカニズムの理解
内的
調査
外的
調査
ミッションクリティカルシステムにおける
性能問題発生から解決までの流れ

12. • ミッションクリティカルシステムにおける性能問題
の考え方
• 性能問題の調査手法の解説
12
－戦術編－

13. 1. 性能問題発生
2. 遅延範囲の確認
3. 応急処置 ※可能な場合
4. 被疑箇所の詳細分析
5. 遅延原因の解明
6. 改善対処(治療)
7. 経過観察
13
8. 解決
• 性能問題の所在(サーバ側かどうか)の特定
• 処理(機能/API)種別の特定
• 被疑ノードの特定
• 応急処置案の見極め
• 流量制御、被疑ノードの切り離し
• 各種分析ツールで情報採取
• CPU時間と待機時間の分析
• 仮説と立証
• サポート問合せ
• 暫定対処(最早解) と 本格対処(最適解)
• 改善効果の評価
• 予兆監視
• 発生条件の特定
• 遅延メカニズムの理解
内的
調査
外的
調査
主なタスク
ミッションクリティカルシステムにおける
性能問題発生から解決までの流れ
今回は 3 まで解説します

14. 1. 性能問題発生
2. 遅延範囲の確認
3. 応急処置 ※可能な場合
4. 被疑箇所の詳細分析
5. 遅延原因の解明
6. 改善対処(治療)
7. 経過観察
8. 解決
内的
調査
外的
調査
混み合ってて、先に進まない！！
一体、何が起きているのか…？
1. 性能問題発生
14

15. 15
外的調査
• 遅延範囲(サービス影響)を把握し、
• 適切な応急処置を見極める。
内的調査
• 被疑箇所の詳細を分析し、
• 遅延原因を解明する。
24x7ミッションクリティカルシステムにおいては、
専門家/有識者がいなくても迅速対応できることが
求められる。
再掲
ミッションクリティカルシステムにおける
性能問題の調査とは？

16. 1. 性能問題発生
2. 遅延範囲の確認
3. 応急処置 ※可能な場合
4. 被疑箇所の詳細分析
5. 遅延原因の解明
6. 改善対処(治療)
7. 経過観察
8. 解決
内的
調査
外的
調査
16
遅延してるのはどのルート？
2. 遅延範囲の把握

17. 17
遅延箇所を可視化できれば、一目瞭然
⇒ 処理(機能/API)種別・ノードを特定可能
<出典: Oracle Management Cloud - Application Performance Monitoring>
https://docs.oracle.com/en/cloud/paas/management-cloud/application-performance-monitoring.html
Oracle Management Cloud
を利用した性能問題調査の例
遅延ノード
を特定
遅延処理を特定
遅延箇所を特定

18. javaプロセス oracle<SID>プロセス
18
遅延箇所を可視化できれば、一目瞭然
⇒ ノード>プロセス>スレッド>処理を特定
実行スレッド (weblogic.kernel.Default)
Web/APサーバ
(WebLogic)
DBサーバ
(OracleDB)
ユーザ
セッション
ソケット通信
スレッド
(weblogic.socket.Muxer)
データ
アクセス層
ビジネス
ロジック層
プレゼン
テーション層
HTTPリクエスト
HTTPレスポンス
スレッド実行 API呼出
SQL発行
SQL実行
API呼出
SQL結果
遅延箇所

19. javaプロセス oracle<SID>プロセス
19
APにトランザクション計測機能を組み込む
⇒ 応答時間・実行回数を時系列で集計しよう
Web/APサーバ
(WebLogic)
DBサーバ
(OracleDB)
HTTPリクエスト
HTTPレスポンス
スレッド実行 API呼出
SQL発行
SQL実行
API呼出
①処理(機能/API)種別
を特定
SQL結果
開始時刻
終了時刻
開始時刻
②AP-DB間ルートを特定
呼出し元AP情報を指定
・JDBC4.0以降ならsetClientInfo()
※DBMS_APPLICATION_INFO相当
終了時刻
実行スレッド (weblogic.kernel.Default)ソケット通信
スレッド
(weblogic.socket.Muxer)
データ
アクセス層
ビジネス
ロジック層
プレゼン
テーション層
ユーザ
セッション
(オプション)
SQL文のコメント部
に処理IDを埋め込む

20. 20
そもそもAPに組み込むことが厳しいときは？
⇒ APM※製品を導入 ※ApplicationPerformanceManagementの略
APM製品を導入すれば、ロジック改変なしに組込可。
• Oracle社
– Oracle Enterprise Manager + Java Flight Recorder
※WebLogic EEで利用可能
※Oracleクラウド(Java CS、Application Container CS)で利用可能
– Oracle Management Cloud (APM Java Agent)
• その他ベンダ
– dynaTrace
– AppDynamics
– New Relic
– CA Introscope
JVM内部調査の
最強ツール

21. 21
あるいは、
専門家/有識者の「現場駆け付け」が頼り
# APM機能の代替手段 留意事項
1 Web/APのアクセスログ
⇒URLを手がかりに遅延した処理を
特定
・アクセスログのURLからは、内部処理を
特定できない場合がある。(あらゆる処理が
同じURLというシステムもある)
※apacheの場合、アクセスログの応答時間にはクライア
ントへのレスポンス送信時間が含まれるので注意。
2 AWR(またはSTATSPACK)、
ASH(またはv$session, その他v$)
⇒DB内部の遅延状況を分析
・SQLの発行元AP処理を特定するのは容易
ではない。(基本はSQL文を手がかりに推定)
3 Javaプロファイラとスレッドダンプ
⇒時間を要している関数を特定
・CPU負荷影響があるため、長時間の情報
採取には適さない。
4 APのログレベルをDEBUGに変更
⇒処理の細部を追跡
・大量ログ出力に伴う性能懸念が想定され
るため、安易に行うのは危険。
・ログ解析作業に時間を要する。
• 調査の作業効率化が鍵となる

22. 1. 性能問題発生
2. 遅延範囲の確認
3. 応急処置 ※可能な場合
4. 被疑箇所の詳細分析
5. 遅延原因の解明
6. 改善対処(治療)
7. 経過観察
8. 解決
内的
調査
外的
調査
22
遅延ルート回避、交通量規制
3. 応急処置

23. 23
• 遅延範囲を手がかりに、応急処置案を見極める。
流量制御
※減らす
被疑ノード
切り離し
(継続調査)
被疑ノード
切り離し
【被疑ノード】
全体的
【処理(機能/API)種別】
全体的
一部
正常ノードのみで継続
※このケースの遅延原因としては、HW
不調や偶発的問題の可能性が想定される。
一部
正常ノードのみで継続
サービスの継続を優先するシステムにおいては、
疑わしき構成要素を積極的にシステムから切り離せ
(“フェールソフト”の考え方)。
<出典：IPA「情報処理システム高信頼化教訓集
（ITサービス編）」2015年度版>
https://www.ipa.go.jp/sec/reports/20160331_1.html
いかにしてサービスを継続させるか？
⇒ まずは応急処置
全体影響の緩和
A) 待ち行列に伴う全体影響
B) CPU負荷に伴う全体影響
そのほかの応急処置として、
・AP資材や設定の戻し
という案もあるが要注意。
カン頼りに応急処置を行うと、
二次被害につながりやすい。

24. 24
流量制御 ※重要度の低い処理を減らす
A) 待ち行列に伴う全体影響の緩和
1. 遅延発生直前で、トランザク
ション量が急増した処理を特定
2. 当該処理を流量制御
3. 待ち行列に伴う全体影響が緩和
調査観点
• トランザクション量を時系列で確認
• システム全体のトランザクション量に対し、
支配的な処理に着目(量が多いもの)
流量制御方法の例
• ロードバランサの流量制御機能
• WebLogicのワークマネージャ機能
• AP多重度、デキュー間隔などの調整
※処置の要否は慎重に判断すること。(例えば、遅延頻度が低なら静観)
「混雑したから遅延した」と
いう仮説に基づく対応となる。
同時スレッド数、接続数、
キュー滞留数、エラー数など、
証拠確認するのが望ましい。

25. 25
流量制御 ※重要度の低い処理を減らす
B) CPU負荷に伴う全体影響の緩和
1. 遅延ノードのCPU使用率を確認
2. CPU負荷が高い場合(※1)、
CPU負荷の高い処理を特定
3. 当該処理を流量制御
4. CPU負荷に伴う全体影響が緩和
調査ツール
• OS(Linux)の場合: top + perf (+gstack)
• Javaの場合: JFR, VisualVM
• DBの場合: AWR, ASH, v$session
調査ツール
• OS(Linux)の場合: mpstat, vmstat
※処置の要否は慎重に判断すること。(例えば、遅延頻度が低なら静観)
流量制御方法の例
• ロードバランサの流量制御機能
• WebLogicのワークマネージャ機能
• AP多重度、デキュー間隔などの調整
※1 CPUのHyperThreading機能を有効にしている際は、
計測されたCPU使用率が80%程度の場合でも、実際の
CPU使用率は限界近いことが想定される。

26. 今回のまとめ
• 大規模システムにおいては、調査の仕組み化が必要
• 遅延範囲の特定は、処理種別毎、ノード毎に行う
• サービス継続優先のため、応急処置案を見極める
• 調査の際は、客観的で事実に即した、的確な分析を
戦略に基づき、迅速な対応を目指しましょう！
26

27. 参考: 被疑箇所調査用のOS(Linux)コマンド
27
# CPU負荷の高いプロセスの調査
top -c -d <計測間隔[秒]>
# プロセス状態の調査 (メモリ使用量, 累計CPU時間, 実行状態)
ps auxfww または ps axww -o user,pid,ppid,stat,rss,etime,cputime,wchan:25,cmd
# プロセス内部で、CPU負荷の高い処理の調査 (関数ごとの%CPU, コールグラフ)
perf record -F 997 -g -o <出力ファイル名> -p <PID> sleep <計測時間[秒]>
perf report -v -n --showcpuutilization --stdio -i <出力したファイル名>
# スタックトレース取得(perfのコールグラフ補完) ※SIGSTOPによる一瞬停止を伴うことに留意
gstack <PID>
# プロセスの外部(システムコール)で待ちが生じている箇所の調査
lsof -p <PID>
strace -f -ff -tt -T -v -x -s 256 -o <出力ファイル名> -p <PID>
• 事前に試験環境(同じOS ver.)で動作検証しておく。
• 影響懸念のあるコマンドは極力使用しない。
【調査に役立ったコマンドの紹介】 想定外の挙動となる可能性に備え、
いきなり本番環境での実行は控える