Download as PDF, PPTX
![参考: 被疑箇所調査用の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.)で動作検証しておく。• 影響懸念のあるコマンドは極力使用しない。【調査に役立ったコマンドの紹介】 想定外の挙動となる可能性に備え、いきなり本番環境での実行は控える](/image.pl?url=https%3a%2f%2fimage.slidesharecdn.com%2foracledatabasejavalinuxpart1-170117172718%2f75%2fOracle-Database-Java-Linux-Part-1-27-2048.jpg&f=jpg&w=240)
Uploaded byShogo Wakayama
PDF, PPTX4,978 views
「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part.1
2017/1/17 JPOUG in 15 minutes #3にて発表した内容です。昨今、システムの大規模(集約)化がトレンドとなっています。そのようなミッションクリティカルシステムにおいて、いかにして性能問題調査を行っていくかを解説します。
![[Oracle DBA & Developer Day 2016] しばちょう先生の特別講義！！ストレージ管理のベストプラクティス ～ASMからExada...](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fmktgdd2-3stragemanagementfordl2-200702092359-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
More Related Content
What's hot
Similar to 「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part.1
「Oracle Database + Java + Linux」 環境における性能問題の調査手法 ～ミッションクリティカルシステムの現場から～ Part.1
- 1.「Oracle Database +Java + Linux」環境における性能問題の調査手法～ミッションクリティカルシステムの現場から～Part. 1若山 勝吾2017. 01. 17© Shogo Wakayama
- 2.
- 3.自己紹介: 若山 勝吾•ミッションクリティカルシステム専門性能改善エンジニア⇒ 性能試験と性能問題解決が得意です。• 10年間、性能プロフェッショナルチームに所属(50を超えるプロジェクトで実績を積む)• Javaプロファイラ、性能モニタリングツール、負荷生成ツールの開発・導入支援を経験3
- 4.
- 5.
- 6.
- 7.7外的調査• 遅延範囲(サービス影響)を把握し、• 応急処置案を見極める。内的調査•被疑箇所の詳細を分析し、• 遅延原因を解明する。24x7ミッションクリティカルシステムにおいては、専門家/有識者がいなくても迅速対応できることが求められる。ミッションクリティカルシステムにおける性能問題の調査とは？
- 8.
- 9.
- 10.
- 11.• 応急処置案の見極め• 流量制御、被疑ノードの切り離し•各種分析ツールで情報採取• CPU時間と待機時間の分析1. 性能問題発生2. 遅延範囲の確認3. 応急処置 ※可能な場合4. 被疑箇所の詳細分析5. 遅延原因の解明6. 改善対処(治療)7. 経過観察118. 解決• 性能問題の所在(サーバ側かどうか)の特定• 処理(機能/API)種別の特定• 被疑ノードの特定• 仮説と立証• サポート問合せ• 暫定対処(最早解) と 本格対処(最適解)• 改善効果の評価• 予兆監視主なタスク• 発生条件の特定• 遅延メカニズムの理解内的調査外的調査ミッションクリティカルシステムにおける性能問題発生から解決までの流れ
- 12.
- 13.1. 性能問題発生2. 遅延範囲の確認3.応急処置 ※可能な場合4. 被疑箇所の詳細分析5. 遅延原因の解明6. 改善対処(治療)7. 経過観察138. 解決• 性能問題の所在(サーバ側かどうか)の特定• 処理(機能/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)種別・ノードを特定可能<出典: OracleManagement Cloud - Application Performance Monitoring>https://docs.oracle.com/en/cloud/paas/management-cloud/application-performance-monitoring.htmlOracle 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>プロセス19APにトランザクション計測機能を組み込む⇒ 応答時間・実行回数を時系列で集計しよう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 IntroscopeJVM内部調査の最強ツール
- 21.21あるいは、専門家/有識者の「現場駆け付け」が頼り# APM機能の代替手段 留意事項1Web/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.)で動作検証しておく。• 影響懸念のあるコマンドは極力使用しない。【調査に役立ったコマンドの紹介】 想定外の挙動となる可能性に備え、いきなり本番環境での実行は控える