「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part.1
8 likes•4,972 views
2017/1/17 JPOUG in 15 minutes #3にて発表した内容です。 昨今、システムの大規模(集約)化がトレンドとなっています。そのようなミッションクリティカルシステムにおいて、いかにして性能問題調査を行っていくかを解説します。
![参考: 被疑箇所調査用の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.)で動作検証しておく。
• 影響懸念のあるコマンドは極力使用しない。
【調査に役立ったコマンドの紹介】 想定外の挙動となる可能性に備え、
いきなり本番環境での実行は控える](https://image.slidesharecdn.com/oracledatabasejavalinuxpart1-170117172718/85/Oracle-Database-Java-Linux-Part-1-27-320.jpg)
「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part.1
- 1. 「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part. 1 若山 勝吾 2017. 01. 17 © Shogo Wakayama
- 3. 自己紹介: 若山 勝吾 • ミッションクリティカルシステム専門 性能改善エンジニア ⇒ 性能試験と性能問題解決が得意です。 • 10年間、性能プロフェッショナルチームに所属 (50を超えるプロジェクトで実績を積む) • Javaプロファイラ、性能モニタリングツール、 負荷生成ツールの開発・導入支援を経験 3
- 7. 7 外的調査 • 遅延範囲(サービス影響)を把握し、 • 応急処置案を見極める。 内的調査 • 被疑箇所の詳細を分析し、 • 遅延原因を解明する。 24x7ミッションクリティカルシステムにおいては、 専門家/有識者がいなくても迅速対応できることが 求められる。 ミッションクリティカルシステムにおける 性能問題の調査とは？
- 11. • 応急処置案の見極め • 流量制御、被疑ノードの切り離し • 各種分析ツールで情報採取 • CPU時間と待機時間の分析 1. 性能問題発生 2. 遅延範囲の確認 3. 応急処置 ※可能な場合 4. 被疑箇所の詳細分析 5. 遅延原因の解明 6. 改善対処(治療) 7. 経過観察 11 8. 解決 • 性能問題の所在(サーバ側かどうか)の特定 • 処理(機能/API)種別の特定 • 被疑ノードの特定 • 仮説と立証 • サポート問合せ • 暫定対処(最早解) と 本格対処(最適解) • 改善効果の評価 • 予兆監視 主なタスク • 発生条件の特定 • 遅延メカニズムの理解 内的 調査 外的 調査 ミッションクリティカルシステムにおける 性能問題発生から解決までの流れ
- 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.)で動作検証しておく。 • 影響懸念のあるコマンドは極力使用しない。 【調査に役立ったコマンドの紹介】 想定外の挙動となる可能性に備え、 いきなり本番環境での実行は控える