| Oracle® Fusion Middleware Oracle Adaptive Access Managerの管理 11gリリース2 (11.1.2.3.0) E67427-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Adaptive Access Managerの管理 11gリリース2 (11.1.2.3.0) E67427-01 |
|
前 |
次 |
パフォーマンス問題を確認するには、パフォーマンス問題が存在するという判断に至った原因を監視し、構成やパフォーマンス情報を使用する必要があります。
この章には次の項が含まれます:
トラブルシューティング・プロセス
トラブルシューティング・プロセスは、トラブルシューティング・フローの最上位から開始します。
OAAMダッシュボードのパフォーマンス・セクションを使用して、ルールおよびポリシーのパフォーマンスを確認します。時間のかかるルールを究明します。
「ダッシュボード」リストで「パフォーマンス」をクリックします。
「データ」リストで、「ルール」または「ポリシー」データ型をクリックします。
データベース・パフォーマンスを確認するには、Fusion Middleware Controlを使用して、SQL問合せのパフォーマンスを確認します。Fusion Middleware Controlから、パフォーマンス向上のために新しい索引の設定を薦められます。
次のようなトランザクション表のサイズ(行数)を確認します。
VCRYPT_TRACKER_NODE
VCRYPT_TRACKER_NODE_HISTORY
VCRYPT_TRACKER_USERNODE_LOGS
VT_DYN_ACT_EXEC_LOG
VT_SESSION_ACTION_MAP
VT_USER_DEVICE_MAP
システム設定で自動学習を使用する場合は、次のような自動学習トランザクション表のサイズを確認します。
VT_WF_DAYS
VT_WF_HOURS
VT_WF_MONTHS
VT_WF_YEARS
V_FPRINTS
前回のアーカイブ/パージ・プロセスがいつ正常に完了したか確認します。このプロセスを設定していない場合は、設定して定期的に実行します。そうしないと、パフォーマンスが低下するおそれがあります。設定手順の詳細は、付録D「アーカイブおよびパージ手順の設定」を参照してください。
前述の手順を適用しても、データベース・パフォーマンスがまだ遅い場合は、詳細分析のためにOracle Databaseから自動ワークロード・リポジトリ(AWR)レポートを生成します。
サーバー・ログを表示します。サーバー・ログは長時間実行されている問合せを出力します(完全なバインド変数により、500ミリ秒を超えると出力されます)。
前述の手順を確認した後で、データベースにI/O問題がある場合は、データベース・マシンまたはディスクをアップグレードする必要があることもあります。
その他の確認
診断ログ、メモリー構成チェック、ネットワーク・ボトルネック、CPUモニタリングを調査します。
最良のパフォーマンスを確実に得られるように、すべてのパフォーマンス領域および関連事項を確認し、ボトルネックの発生場所を特定します。データを収集し、I/Oのボトルネックを調査することにより、DBAや設計者が問題を解決するための選択肢が広がります。システムが想定どおりに動作しないときには、応答時間が長くなったり、タイムアウトが頻繁に発生することがあります。
Fusion Middleware Controlで主要なメトリックをモニターすることもできます。
アプリケーション・サーバーとデータベース間の接続、jStackのスタック・トレースおよびスレッド・ダンプを確認します。
次のOAAMプロパティを確認します。
bharosa.db.query.performance.warning.print.stack=false bharosa.db.query.performance.warning.threshold.ms=500 (print WARN for every call that takes more than 0.5 secs, this can be adjusted for optimal value other than this). bharosa.db.query.performance.warning.print.stack=true
OAAM APIに対するコールが時間の経過とともに悪化する場合
OAAM APIに対するコールが時間の経過とともに悪化する場合、次のような原因が考えられますので確認してください。
データベースが大きくなりすぎています。データベースから古いデータを定期的にアーカイブおよびパージすることで、問題を回避できます。
サーバー・マシン上のハード・ドライブが一杯になっている可能性があります。この場合、アプリケーションの速度低下または停止につながる様々な問題が発生します。
アプリケーション・サーバーを正常に動作させるためのバイナリが破損しています。Webコンテナのアプリケーション・ディレクトリ内に最近の変更時刻または通常と異なる変更時刻がないか確認します。
1秒当たりのユーザーまたはトランザクションの数が、システムが設計上処理できる数を超えています*。これを解決するには、ハードウェアを追加したり、より高度な受信接続処理を行う必要があります。
*参照用のステージング・ハードウェア/ソフトウェア環境でデプロイ前のパフォーマンス・テストを実施し、取得したメトリックを利用することにより、処理可能な最大同時セッション数および1秒当たりのセッション数を特定してください。
使用環境のパフォーマンスをモニターして改善するには、使用可能なツールと各ツールの使用方法を理解しておく必要があります。
この項では、次の各ツールについて、その用途およびパフォーマンス関連のデータを収集するための使用方法を説明します。
ダッシュボード
ダッシュボードを使用すると、システムのパフォーマンスをより明確に把握できます。統計情報によって、ルール、ポリシー、チェックポイントおよびAPIの処理にかかった時間を確認できます。ルール、ポリシーおよびチェックポイントの実行にかかっている平均処理時間はどれぐらいですか。最も多くリソースを消費するアイテム(最もコストが高いおよび低いルールなど)を特定できます。今日、過去1日、過去7日間、過去30日間または過去90日間のデータを表示できます。また、ログイン回数、KBAまたはOTPのチャレンジ回数および1分当たりのトランザクション件数を表示できます。
ダッシュボードにはシステムのヘルスに関するデータが表示されます。これを使用して、ボトルネックの有無を判断できます。また、「セッション詳細」ページも便利なツールであり、このページには、実行されたルールやポリシーの概要、および収集された詳細情報(実行時間、タイムスタンプ、ランタイム、実行されたルールの数、追加のデータなど)が表示されます。
ダッシュボードを起動するには、OAAMのナビゲーション・ツリーで「ダッシュボード」をダブルクリックします。ダッシュボードがOAAM管理コンソールの右側に表示されます。
ルール・ログ
ルール・ログのBI Publisherレポートを作成すると、サマリー情報およびパフォーマンスのボトルネックが潜在する場所の特定に役立つ情報をすばやく収集できます。
レポートによって、ルールに関する詳細情報を表示できます。「セッション詳細」ページにはルールの実行時間が表示されます。ルールで異常なほどの時間がかかる場合は、さらに分析を行います。また、各ランタイムの実行を確認します。問合せを印刷するのに何秒かかりますか。そのしきい値よりも問合せに時間がかかる場合は、その問合せを印刷します。
Javaプロファイリング
アプリケーションのCPU使用率が高く、データベースの動作速度が期待どおりではない場合、JAVAプロファイリング・ツールを使用できます。これらのツールにより、多くの時間を要するメソッド、コードおよびクラスに関するデータが提供されます。これらのツールを使用すると、実行の発生回数および実行の合計時間に関する問題を解決できます。
Oracle Fusion Middleware Control
Oracle Adaptive Access Managerのパフォーマンスおよびアクティビティのモニターには、Fusion Middleware Controlを使用できます。
「Identity and Access」で「OAAM」を選択して、ホームページに移動します。
ホームページで、Oracle Adaptive Access Managerのパフォーマンス概要を確認できます。
ホームページの左上にある「Oracle Adaptive Access Manager」メニューから「パフォーマンス・サマリー」を選択して、パフォーマンス・メトリックを表示します。
Fusion Middleware Controlを使用したステータスおよびパフォーマンスのモニタリングの詳細は、管理者ガイドのOracle Fusion Middlewareのモニタリングに関する項を参照してください。
その他の環境依存ツール
その他の環境依存ツールを使用します。
次の各項では、OAAMパフォーマンスのベスト・プラクティスをいくつか示します。
ほとんどの場合、パフォーマンスへの対応時に、ルールおよびポリシーの作成に着目する必要はありません。ただし、どのテクノロジにも言えることですが、パフォーマンスを最大化するのに役立つヒントやコツがありますので、必要に応じて利用してください。この項の考慮事項の大半は、構成に関するものです。
最初に単純な条件のルールを順序付ける
ルール条件の順序を変更すると、時間またはメモリー使用量、あるいはその両方の点でルール評価のパフォーマンスが向上します。プロパティまたは小さな変数をチェックするなど、単純なルールを構成し、評価順序の最初に実行します。自動学習(動的条件)など、複雑な条件を含むルールを構成し、単純なルールの後に実行します。ルールがtrueと評価されると、評価は停止します。たとえば、最初のルールがtrueを返した場合、2番目のルールの評価は試行されません。
ポリシーの構造および動作を検討する
処理に非常に多くの時間を要するルールを分離し、ポリシーを確認してパフォーマンス問題が存在すると思われる場所を特定します。たとえば、ポリシーに関連付けられているすべてのルールを実行する際に非常に時間がかかる場合は、ポリシーに関連付けられているルールが多すぎるか、より高負荷のルールが使用されていることが考えられます。ルールが多すぎる場合は、これらを別々のポリシーに分割することを検討します。高負荷のルールがある場合は、基礎となるSQL問合せの最適化、またはデータベースの最適化/チューニングを検討します。
条件を何度も実行するのは非効率であるため、それらの条件をネストする
結果によってアクションを実行するか、特定のユーザーにスコアを渡す、または機能が有効な場合にスコアを渡すポリシーがあります。特定のユーザーまたは有効な機能を様々なルールで確認するために、いくつもの条件が繰り返される場合は、かわりにその条件をいずれかのポリシーの決定ポイントにし、このポイントから別のフローを続行します。たとえば、条件で特定のタイプのユーザーをチェックする場合、同じ条件を何度も評価することにより同じユーザーが評価されます。条件でユーザーが携帯電話ユーザーかどうかを確認し、該当するユーザーの場合はあるアクションを実行してスコアを渡し、さらにまた、ユーザーが携帯電話ユーザーかどうかを確認して、該当するユーザーの場合は別のアクションを実行して別のスコアを渡す、といった場合です。そのように条件を評価するのではなく、ポリシーをネストする方法を検討します。ユーザーが携帯電話カスタマかどうかを確認し、該当する場合は前述のそれぞれのポリシーを実行するように評価を設定します。この方法の場合、条件が何度も実行されることはありません。
すべてのオーバーライドを評価しなくても済むようにルールを順序付ける
オーバーライドはありますか。オーバーライド(トリガー組合せ)は、ルールの結果をオーバーライドするために使用します。「トリガー組合せ」タブでは、トリガー組合せの各行は、ポリシーを提示しているルールを表します。ポリシーに一連のトリガー組合せがある場合、各行はルールに相当します。縦の列は、トリガーするまたはしないルールの組合せを表します。トリガー組合せは、列1から列2、3、4と移動しながら順に評価し、ルール・リターンが一致すると停止します。
より複雑なルールを特定し、それらのルールが先に評価されるように配置します。最初の列がTrueの場合、2番目の列は評価されません。すべてのオーバーライドが評価されずに済むようにルールを配置します。
必要なルール、パターンおよびログのみを維持する
必要なルールのみを維持します。使用していないルールは、無効化または削除できます。セッションが実行されるたびにルールによって問合せが追加されます。その問合せが必要でなければ、データベースで追加の問合せを実行する必要はありません。OAAMには標準のデバイス・ルールが付属しています。評価時にデバイスを使用する予定がない場合は、デバイス用のルールをすべて無効化できます。
必要なパターンのみを維持します。ルールでパターンを使用していない場合は、それらのパターンを無効化または削除します。操作を実行し、セッションが実行されるたびに、自動学習によって5個から10個の問合せが潜在的に実行される場合があります。データベースで問合せが実行されると、パフォーマンスに影響します。
必要な更新(ルール・ログなど)のみを維持します。OAAMデータベースにはルール・ログが機能として用意されています。ルール・ログはデータベースの表を更新します。調査時の分析対象としてすべてのセッションを使用する必要がない場合は、詳細ルール・ログを完全にオフにするか、必要な時間のみ(5秒間など)有効にすることができます。
デプロイメントに必要なリソース・バンドルを特定する
リソース・バンドルは、アプリケーションの国際化のために使用されるロケール固有のデータを含むプロパティ・ファイルです。
すべてのリソース・バンドルが必要かどうか、また、一部のリソース・バンドルは削除できるかどうかを検討します。デプロイメントがマルチリンガルでない場合、またはすべてのリソースおよびロケールが必要ではない場合は、一部のリソース・バンドルについて使用しないことを検討します。
軽量なアプリケーションおよびポリシー/ルール構成を使用する
軽量なアプリケーションおよびポリシー/ルールを使用します。カスタム・デプロイメントでは、ポリシー、ルールおよびアクションの追加時に、必要なリソースを検討します。
ルール・ロギング
ルール・ロギングには大量のデータが含まれます。1日のログイン回数が多いユーザーの場合、ログに書き込まれるデータの行が多くなります。
実行時間がしきい値を超える場合にのみ詳細ルール・ログが作成されるようにルール・ロギングを構成できます。実行時間の長いルール(ランタイム)に関する詳細がロギングされるため、詳細ロギングのオーバーヘッドはかなり大きくなります。詳細ロギングが行われる前に必要な最小時間を設定する場合は、次のプロパティを設定する必要があります。
vcrypt.tracker.rulelog.detailed.minMillis=time
ロギング
Oracle Adaptive Access Manager 11gコンポーネントでは、ロギング・インフラストラクチャの一部としてjava.util.loggingパッケージを使用します。このパッケージは、すべてのJava環境で使用できます。OAAMロガーは、エラーを報告したりOAAMの追加情報を提供するロギング・メッセージを生成します。
どの程度のロギングが必要ですか。ログ・レベルは、どのメッセージをログに書き込むかを定義するために使用されます。ログの出力量を減らすことによりパフォーマンスが向上します。
ロギング構成にアクセスするには:
管理者としてFusion Middleware Controlにログインします。
「WebLogicドメイン」でoaam_server_server1をクリックします。
「WebLogic Server」タブ、「ログ」を展開し、「ログ構成」を選択します。
「ログ・レベル」をクリックし、「ルート・ロガー」→「oracle」を展開して「oracle.oaam」を選択します。
ログ・レベルを必要なレベルに設定します。
デバッグおよびトレース
デバッグとトレースを有効にするには、次の手順を実行します。
Oracle WebLogic Scripting Tool (WLST)の環境を設定します。
次を入力して、IAM_ORACLE_HOME/common/binディレクトリに移動します。
cd IAM_ORACLE_HOME/common/bin
次のコマンドを実行して、WLSTシェル環境に入ります。
./wlst.sh
Connectと入力し、WebLogic管理サーバーに接続します。
ユーザー名を入力します。たとえば、admin_usernameなどです。
パスワードを入力します。たとえば、admin_passwordなどです。
t3://hostname:portを入力します。
次に例を示します。
t3://AdminHostname:7001
domainRuntime()を入力します。
wls:/iam_domain/domainRuntime> setLogLevel(logger="oracle.oam",level="TRACE:32", persist="0", target="oam_server1") wls:/iam_domain/domainRuntime> listLoggers(pattern="oracle.oam.*",target="oam_server1")
データベース・アクティビティの量
データベース・アクティビティの量は、いくつかの要因によって決まります。
ユーザー、デバイス、ブラウザが新規か、または既存か
自動学習を使用する場合、パターンの数
定義されているポリシーとルールの数、およびチェックポイントの数
プロパティbharosa.db.query.performance.warning.threshold.msがゼロに設定されている場合、OAAMではすべてのSQLを出力します。
このプロパティを設定し、通常のログインを試行した後で、ログ・メッセージに対して文字列ms execution forまたはSQLCallをgrepしてください。
これにより、データベースの標準的なログイン・アクティビティを見積もることができます。
使用領域を判別するためのデータベース問合せ
次の問合せを使用して、表内の行の平均サイズを判別します。
.
select table_name,
avg_row_len
from user_tables
.
次の問合せを使用して、表の索引のサイズを判別します。
.
select inds.table_name,
inds.index_name,
sum( inds.sizes ) as index_bytes_per_row
from (
select i.index_name,
i.table_name,
i.column_name,
decode(data_type, 'DATE' , 7,
'CHAR' , data_length,
'VARCHAR2', decode(
sign(data_length)-250, -1, .7*data_length+3, .7*data_length+1),
'NUMBER' ,
floor(nvl(data_precision,38)/2)+2 ) as sizes
from user_ind_columns i,
user_tab_columns t
where t.TABLE_NAME = i.table_name AND
t.COLUMN_NAME = i.COLUMN_NAME
order by i.table_name, i.column_name
) inds
group by inds.table_name, inds.index_name;
データベースのチューニング・プラクティス
OAAMには、パフォーマンス・テストに基づいて作成された標準の索引があります。
ほとんどのデプロイメントではこれらの標準の索引で間に合いますが、パフォーマンス・テスト後にデータベース管理者が必要であると判断した場合は、別の索引を追加することもあります。ただし、トランザクションのユース・ケースが関連する場合を除き、このようなことはまれです。
挿入と更新が効率的に行われるように、データベース管理者が、データベース・サーバー・パラメータを調整してI/Oをチューニングすることもあります。
データベース管理者は、データベース・サーバーが安定するまで本番環境をモニターする必要があります。
Oracleのパーティション化オプション
パーティション化は、Oracle Database 11g Enterprise Editionの標準の機能を拡張するオプションの1つです。
1日のログインまたはトランザクションが100Kを超えるようなデプロイメントに対しては、パーティション化を使用することをお薦めします。Oracle Fusion Middleware Repository Creation Utility (RCU)の実行中は、パーティション化されたスキームが使用されます。
500GB以上のデータベースでは、パーティション化を使用する必要があります。
OAAMデータベース索引の競合 - Oracle Real Application Cluster (Oracle RAC)固有
高い索引競合が発生した場合、次の索引をパーティション化します。
PK_VT_TRX_LOGS
PK_VT_ENT_TRX_MAP
VT_TRX_LOGS_IDX3
VT_WF_MONTHS_IDX1
PK_VT_TRX_DATA
VT_WF_YEARS_IDX0
VT_WF_MONTHS_IDX0
VT_TRX_LOGS_IDX6
また、VT_USER_PROFILE表もパーティション化します。
データベースのI/O (入力/出力)
データベースのI/O (入力/出力)パフォーマンスに関する問題は、問合せの実行に時間がかかる場合に発生することがあります。
監査および問合せ
問合せや監査のアクティビティにより本番の索引および表領域に対して多数の順次読取りや表スキャンが実行される場合があります。パフォーマンスへの影響を軽減するには、DataGuard (ロジカル・スタンバイ・データベースを使用したレポートの問合せ、監査および実行を選択できます)を使用してロジカル・スタンバイ・データベースを管理することを検討してください。ロジカル・スタンバイ・データベースには、過去1時間を除くすべての本番データが含まれます。本番データベース・インスタンスは、挿入や更新などの実行、またアクティブなモニタリングやアラートに対しても使用できます。
メモリーでの実行
ほとんどの実行がメモリーで処理されるようにアプリケーションまたはコンテンツを構成します。
キャッシュ
キャッシュは、問合せ結果を格納して、後で使用できるようにする機能を持ちます。毎回データベースから情報を取得するのではなく、キャッシュを使用して問合せの結果を返します。情報がすでにキャッシュに存在していることが望ましいとされます。たとえば、ユーザー登録のキャッシュなどです。
キャッシングに関連する高メモリー使用率
最大キャッシュ・サイズを制御するために使用できるプロパティがあります。このようなプロパティを次に示します。
表29-1 キャッシュ・サイズ・プロパティ
| プロパティ名 | キャッシュされるオブジェクト | デフォルト値 |
|---|---|---|
|
vcrypt.fingerprint.cache.maxsize |
フィンガープリント |
10000 |
|
bharosa.tracker.location.location.cache.maxsize |
IPのロケーション |
1000 |
|
bharosa.tracker.location.city.cache.maxsize |
市区町村 |
1000 |
|
bharosa.tracker.location.state.cache.maxsize |
都道府県 |
1000 |
|
bharosa.tracker.location.country.cache.maxsize |
国 |
1000 |
変更後、サーバーの再起動が必要です。
適切なプロパティを設定した場合、キャッシュは設定したサイズまで増加し、一杯になった後は、新しいエントリが挿入されると、使用日時が最も古いエントリが削除されます。
ディスクI/Oの削減
ロギング・レベル: 不要なロガーが有効化されていないことを確認します。
特定用途のアプリケーションに対してJVMの設定が正しく行われていることを確認します。設定を正しく構成しましたか。標準のOAAMでは、これらの設定のほとんどは最適化されています。
低速なデータベースの場合、ディスクI/Oが増加する可能性があります。その結果、アプリケーションの実行速度が低下します。
ネットワーク・コール
リモート・データベースの場合、データベースの問合せに複数のホップが必要になる可能性があります。ホップ数が増えるほど、ソースから宛先にデータが到達するまでにより時間がかかります。また、Webサービス/SOAPを使用していて、作成されるセッション数が多い場合は、入力に影響が及ぶ可能性もあります。
SOAPコール
ネットワークに問題があるかどうか確認します。
タイムアウトの回数を調べます。ネットワークが正しく設定されていることを確認します。
.Net/SOAPのWebサービス統合OAAMデプロイメントが遅い
.Net/SOAPアプリケーションとOAAMサーバーの間のネットワーク通信が最適化されていることを確認します。遅延を発生させる余分なホップはなくす必要があります。
