「Oracle Database + Java + Linux」環境における性能問題の調査手法...

「Oracle Database + Java + Linux」環境における性能問題の調査手法

～ミッションクリティカルシステムの現場から～

Part. 1

若山勝吾

2017. 01. 17

© Shogo Wakayama

はじめに

昨今、システムの大規模(集約)化がトレンドとなっています。そのようなミッションクリティカルシステムにおいて、いかにして性能問題調査を行っていくかを解説します。

2

仮想化

クラウド化

マルチテナント

大規模

(集約)化

スケールアウト構成

情報量の爆増

24時間無停止

かさむ保守・運用費

既存システムのHW老朽化

予測困難な突発的トラフィック

被災時対策

製品サポート期間の終了

サービス連携の多様化

ログ蓄積の限界

設備設置スペース不足

迅速なAP開発要件

複数システムをとりまく課題の例

新たなシステム構成

パッチ最新化

自己紹介: 若山勝吾

• ミッションクリティカルシステム専門性能改善エンジニア

⇒ 性能試験と性能問題解決が得意です。

• 10年間、性能プロフェッショナルチームに所属(50を超えるプロジェクトで実績を積む)

• Javaプロファイラ、性能モニタリングツール、負荷生成ツールの開発・導入支援を経験

3

アジェンダ

• ミッションクリティカルシステムにおける性能問題の考え方

• 性能問題の調査手法の解説

4



5

－戦略編－

ミッションクリティカルシステムにおける性能問題とは？

• 性能に起因するサービス影響のこと。

• 処理遅延は性能問題である。

6

処理遅延

許容範囲を超過

スループット

低下

リソース

使用率が高

燃費としては悪い

処理遅延する寸前

処理遅延するとスループットも低下

リソース限界時は応答時間が遅延

対象の業務量が少ないだけかも

性能問題

7

外的調査

• 遅延範囲(サービス影響)を把握し、

• 応急処置案を見極める。

内的調査

• 被疑箇所の詳細を分析し、

• 遅延原因を解明する。

24x7ミッションクリティカルシステムにおいては、専門家/有識者がいなくても迅速対応できることが求められる。

ミッションクリティカルシステムにおける性能問題の調査とは？

クライアント側サーバ側

本番環境で処理遅延が発生！①あなたなら、どこから調査しますか？

8

遅い！

遅い！

遅い！

遅い！

Web/APサーバ

(WebLogic)

DBサーバ

(OracleDB)

小規模であれば、得意なレイヤから調査するのもアリ。(処理種別・ノードが少なければ消去法作戦が可能)

FW/LB

サーバ側で遅いな

調査対応者

ユーザ

SW

性能問題の所在説明をシンプルにするため、サーバ側に問題がある状況としています。

WAN

9

WAN

DBサーバ

(OracleDB)

本番環境で処理遅延が発生！②あなたなら、どこから調査しますか？

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

大規模であれば、調査の仕組み化が必要不可欠。(仕組みが無いと、高度な専門知識があっても苦戦)

FW/LB

Web/APサーバ

(WebLogic)

調査対応者

クライアント側

ユーザ

SW

バッチ系

OLTP系業務DB

ユーザ管理DB

サーバ側で遅いな

性能問題の所在

調査対象が多くて大変！

サーバ側説明をシンプルにするため、サーバ側に問題がある状況としています。

10

WAN

処理遅延が発生！③調査完了するまで、状況を放置して大丈夫？

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

遅い！遅い！

ミッションクリティカルシステムでは、サービス継続を優先することが重要。(原因解明は後回しでよい)

もう我慢限界！！

クライアント側

ユーザ DBサーバ

(OracleDB)

FW/LB

Web/APサーバ

(WebLogic)

調査対応者

SW

バッチ系

OLTP系業務DB

ユーザ管理DB

性能問題の所在

一体何が原因だろう…

見落としはないよな…

サーバ側

• 応急処置案の見極め• 流量制御、被疑ノードの切り離し

• 各種分析ツールで情報採取• CPU時間と待機時間の分析

1. 性能問題発生

2. 遅延範囲の確認

3. 応急処置 ※可能な場合

4. 被疑箇所の詳細分析

5. 遅延原因の解明

6. 改善対処(治療)

7. 経過観察

118. 解決

• 性能問題の所在(サーバ側かどうか)の特定• 処理(機能/API)種別の特定• 被疑ノードの特定

• 仮説と立証• サポート問合せ

• 暫定対処(最早解) と本格対処(最適解)• 改善効果の評価

• 予兆監視

主なタスク

• 発生条件の特定• 遅延メカニズムの理解

内的調査

外的調査

ミッションクリティカルシステムにおける性能問題発生から解決までの流れ



12

－戦術編－



3. 応急処置 ※可能な場合




7. 経過観察

138. 解決

• 性能問題の所在(サーバ側かどうか)の特定• 処理(機能/API)種別の特定• 被疑ノードの特定

• 応急処置案の見極め• 流量制御、被疑ノードの切り離し

• 各種分析ツールで情報採取• CPU時間と待機時間の分析

• 仮説と立証• サポート問合せ

• 暫定対処(最早解) と本格対処(最適解)• 改善効果の評価

• 予兆監視

• 発生条件の特定• 遅延メカニズムの理解

内的調査

外的調査

主なタスク

ミッションクリティカルシステムにおける性能問題発生から解決までの流れ

今回は 3 まで解説します



3. 応急処置※可能な場合




7. 経過観察

8. 解決

内的調査

外的調査

混み合ってて、先に進まない！！

一体、何が起きているのか…？


14

15

外的調査

• 遅延範囲(サービス影響)を把握し、

• 適切な応急処置を見極める。

内的調査

• 被疑箇所の詳細を分析し、

• 遅延原因を解明する。

24x7ミッションクリティカルシステムにおいては、専門家/有識者がいなくても迅速対応できることが求められる。

再掲ミッションクリティカルシステムにおける性能問題の調査とは？







7. 経過観察

8. 解決

内的調査

外的調査

16

遅延してるのはどのルート？

2. 遅延範囲の把握

17

遅延箇所を可視化できれば、一目瞭然⇒ 処理(機能/API)種別・ノードを特定可能

<出典: Oracle Management Cloud - Application Performance Monitoring>

https://docs.oracle.com/en/cloud/paas/management-cloud/application-performance-monitoring.html

Oracle Management Cloudを利用した性能問題調査の例

遅延ノードを特定

遅延処理を特定

遅延箇所を特定

javaプロセス oracle<SID>プロセス

18

遅延箇所を可視化できれば、一目瞭然⇒ ノード>プロセス>スレッド>処理を特定

実行スレッド (weblogic.kernel.Default)

Web/APサーバ

(WebLogic)

DBサーバ

(OracleDB)

ユーザセッション

ソケット通信スレッド

(weblogic.socket.Muxer)

データアクセス層

ビジネスロジック層

プレゼンテーション層

HTTPリクエスト

HTTPレスポンス

スレッド実行API呼出

SQL発行SQL実行

API呼出

SQL結果

遅延箇所

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

そもそも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

あるいは、専門家/有識者の「現場駆け付け」が頼り

# 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に変更⇒処理の細部を追跡

・大量ログ出力に伴う性能懸念が想定されるため、安易に行うのは危険。・ログ解析作業に時間を要する。

• 調査の作業効率化が鍵となる







7. 経過観察

8. 解決

内的調査

外的調査

22

遅延ルート回避、交通量規制

3. 応急処置

23

• 遅延範囲を手がかりに、応急処置案を見極める。

流量制御

※減らす

被疑ノード

切り離し

(継続調査)被疑ノード

切り離し

【被疑ノード】全体的

【処理(機能/API)種別】全体的

一部

正常ノードのみで継続※このケースの遅延原因としては、HW不調や偶発的問題の可能性が想定される。

一部

正常ノードのみで継続

サービスの継続を優先するシステムにおいては、疑わしき構成要素を積極的にシステムから切り離せ(“フェールソフト”の考え方)。

<出典：IPA「情報処理システム高信頼化教訓集（ITサービス編）」2015年度版>

https://www.ipa.go.jp/sec/reports/20160331_1.html

いかにしてサービスを継続させるか？⇒ まずは応急処置

全体影響の緩和A) 待ち行列に伴う全体影響B) CPU負荷に伴う全体影響

そのほかの応急処置として、・AP資材や設定の戻しという案もあるが要注意。カン頼りに応急処置を行うと、二次被害につながりやすい。

24

流量制御 ※重要度の低い処理を減らす

A) 待ち行列に伴う全体影響の緩和

1. 遅延発生直前で、トランザク

ション量が急増した処理を特定

2. 当該処理を流量制御

3. 待ち行列に伴う全体影響が緩和

調査観点• トランザクション量を時系列で確認• システム全体のトランザクション量に対し、

支配的な処理に着目(量が多いもの)

流量制御方法の例• ロードバランサの流量制御機能• WebLogicのワークマネージャ機能• AP多重度、デキュー間隔などの調整

※処置の要否は慎重に判断すること。(例えば、遅延頻度が低なら静観)

「混雑したから遅延した」という仮説に基づく対応となる。同時スレッド数、接続数、キュー滞留数、エラー数など、証拠確認するのが望ましい。

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

参考: 被疑箇所調査用の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.)で動作検証しておく。

• 影響懸念のあるコマンドは極力使用しない。

【調査に役立ったコマンドの紹介】想定外の挙動となる可能性に備え、いきなり本番環境での実行は控える

「Oracle Database + Java + Linux」環境における性能問題の調査手法...

Technology

Transcript of 「Oracle Database + Java + Linux」環境における性能問題の調査手法...