| Oracle® Fusion Middlewareパフォーマンスのチューニング・ガイド 12c (12.2.1.2) E82648-01 |
|
 前へ |
 次へ |
ワーク・マネージャおよびその他のチューニング・パラメータを使用してSOAインフラストラクチャをチューニングし、Oracle WebLogic Serverでコンポジットとそのライフサイクル、サービス・エンジンおよびバインディング・コンポーネントを管理する際のパフォーマンスを最適化できます。
親トピック: SOA Suiteのコンポーネント
SOAインフラストラクチャは、Oracle WebLogic Serverで実行されるJava EE準拠のアプリケーションです。
アプリケーションでは、コンポジットとそのライフサイクル、サービス・エンジンおよびバインディング・コンポーネントが管理されます。詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、SOAインフラストラクチャ・アプリケーションの概要に関する項を参照してください。
ここでは、全体的なアプローチに必要な診断ツールや手法は対象としませんが、単一の症状に対する個別のチューニング・オプションについて説明します。問題のある領域を特定するためのSOAインフラストラクチャのパフォーマンス・モニタリングの詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、SOAインフラストラクチャのモニタリングに関する項を参照してください。
ワーク・マネージャを利用するために、いくつかの簡単なチェックおよび構成を実行できます。
Oracle SOA Suite 12c (12.2.1)から、ワーク・マネージャはほとんどのSOA関連ワーク・スレッドを処理するようになりました。ワーク・マネージャがスレッドを管理して自己チューニングする方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverサーバー環境の管理で、ワーク・マネージャの理解に関する項を参照してください。
ワーク・マネージャの構成を試みる前に、使用する環境をよく理解し、次を定量化できる必要があります。
処理が必要な受信リクエストのボリューム
トランザクションのSLA予測を含む内部処理要件
イベント配信ネットワークやほとんどのアダプタなど、ワーク・マネージャを使用しないプロセスの理解
ここで収集した情報に基づいて、ワーク・マネージャの自己チューニング機能を利用できます。
SOADataSourceプロパティでのデータベース接続の構成SOADataSourceプロパティは、SOAプロセスに使用可能な同時データベース接続の総数を決定します。SOAプロセスはほとんどのアクティビティにデータベースを使用するため、これは非常に重要な設定であり、適切に構成しないとボトルネックとなる可能性があります。
この設定をチューニングするには、使用するデータベース・リソースについて理解し、DBAに助言を求めることが重要です。
SOADataSourceをチューニングするには、次の手順を実行します。
「最大容量」属性のデフォルトは50です。最も実用的なユースケースのために、この値を300に設定してSOADataSource接続プール全体のサイズを大きくする必要があります。
SOADataSource設定は、SOAMaxThreadsConfig属性でのワーク・マネージャの構成に説明されているSOAMaxThreadConfig構成によって利用されます。SOADataSourceはすべてのワーク・マネージャが使用できる接続の総数を定義し、SOAMaxThreadConfig属性は、それらの接続のなかでワーク・マネージャの特定のカテゴリが使用できる接続の割合を定義します。
SOAMaxThreadsConfig属性でのワーク・マネージャの構成SOAコンポジットには、様々なコンポーネントおよび機能領域を処理するワーク・マネージャのグループが関連付けられます。SOAMaxThreadsConfig属性は、ドメイン内の異なるSOAワーク・マネージャのグループに許可されるスレッド数を決定します。
受信リクエスト、内部プロセスおよびその他のSOAプロセスを処理するために割り当てられるスレッド数は、SOADataSourceプロパティでのデータベース接続の構成に説明されているSOADataSourceプロパティの割合として定義されます。SOAMaxThreadsConfig属性のデフォルトの割合の値とカテゴリを表11-1に示します。
表11-1 SOAMaxThreadsConfigによって決定されるワーク・マネージャに対するスレッド配信
| グループ | 説明 |
|---|---|
デフォルト: 20% |
このパラメータは、受信クライアント・リクエストを処理するワーク・マネージャにシステムが割り当てるスレッドの割合を決定します。 |
デフォルト: 30% |
このパラメータは、EDNやアダプタなど、その他のSOA機能に配信されるスレッドの割合を決定します。 |
デフォルト: 50% |
このパラメータは、内部プロセス用にシステムがワーク・マネージャに割り当てるスレッドの割合を決定します。 |
この属性はドメイン・レベルで定義され、そのドメインにあるすべてのワーク・マネージャに適用されます。Fusion Middleware Control MBeanブラウザでSoaInfraConfig MBeanを使用してこの属性を設定できます。
属性にアクセスするには、次の手順を実行します。
この画面で調節している値は、スレッドの個別の数ではなく割合であることに注意してください。SOADataSourceプロパティでのデータベース接続の構成に説明されているSOADataSourceプロパティの値を調べることで、使用できるスレッドの総数を確認する必要があります。
SOADataSourceが50接続に設定され、表11-1に示されているデフォルトのSOAMaxThreadConfigの割合を保持しているサンプル・シナリオでは、次のスレッド割当てになります。
50の20% = 10のスレッドが受信リクエストを処理します
50の30% = 15のスレッドがワーク・マネージャを使用しないプロセス用です
50の50% = 25のスレッドが内部プロセスを処理します
SOAインフラストラクチャのパラメータのチューニングは、パフォーマンスを最適化するうえで重要です。
表11-2に、SOAインフラストラクチャのパフォーマンスに最も大きい影響を与えるパラメータの最適な設定を示します。
表11-2 重要なSOAインフラストラクチャのチューニング
| パラメータ | 問題点 | チューニングに関する推奨事項 | トレードオフ |
|---|---|---|---|
デフォルト: |
|
予想されるパフォーマンス低下を防ぐために、監査レベルを「オフ」にします。 このパラメータはEnterprise Managerで設定できます。「SOAインフラストラクチャの共通プロパティ」ページに このページを見つけるには、次の手順を実行します。
このパラメータの詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、Oracle SOA SuiteおよびOracle BPM Suiteプロファイルの構成に関する項を参照してください。 |
デフォルトの監査レベルを維持すると、監査データが生成されてデータベースで取得されるため、データベース増大の原因になります。ユーザーは、監査情報を利用してエラーをデバッグする必要があります。 |
デフォルト: 毎日深夜に、7日以上経過したレコードをパージします |
|
|
この機能を無効にすると、進行中のデータベース増大の保守にさらに時間がかかります。 |
特定のシナリオでは、SOAの追加のパフォーマンス・チューニング設定を構成することができます。
ここに記載されているオプションは特定の順序で並んではいません。これらのプロパティを変更する前に、使用する環境、SOAプロセスおよび非SOAプロセスについて全体的に理解しておく必要があります。
高度なパフォーマンス最適化は、個別のシナリオ、設定、環境および予測に対してカスタマイズされた方法にする必要があることを理解することが重要です。カスタマイズされた方法には、最適化が必要なボトルネックおよび領域を特定して分離するために、詳細な診断情報の取得が必要です。
問題のある領域を特定するためのSOAインフラストラクチャのパフォーマンス・モニタリングの詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、SOAインフラストラクチャのモニタリングに関する項を参照してください。
コンポジットの遅延ロードは12cの新機能です。多数のコンポジットがデプロイされているとき、これによってサーバー起動時間が改善されます。
サーバー起動時に、最小限のコンポジットがロードされ、つまり、メモリー内のJavaモデルおよびMBeanのみが作成されます。コンポジットによって使用されるコンポーネントやリソースのロードなどの初期化タスク、つまり、WSLDおよびスキーマ・ファイルは、後で必要になって最初に要求されたときにロードされます。
これによってサーバー起動時間が大幅に改善され、リクエストを受信するときのコンポジット起動時間がずれて、ほとんど使用されないまたはリタイアしたコンポジットによるオーバーヘッドが削減されます。
コンポジットの遅延ロードは次の場合に役立ちます。
サーバー障害時に迅速な障害回復時間を必要とするシナリオ
サイズが大きいWSDLSまたはスキーマ・ファイルを使用するコンポジットを大量に持つ顧客
コンポジットの遅延ロードはデフォルトで有効であり、ドメイン・レベルおよびコンポジット・レベルで構成できます。
コンポジットの遅延ロードは、デフォルトでドメイン・レベルで有効です。この設定は、Fusion Middleware ControlのEnterprise ManagerのシステムMBeanブラウザから無効にできます。この設定への変更は、サーバーの再起動時に有効になります。
ドメイン・レベルの遅延ロード機能の設定を変更するには、次の手順を実行します。
CompositeLazyLoading属性を探してクリックします。CompositeLazyLoadingページで、値をtrueに設定して有効にするか、falseに設定して無効にすることができます。変更の準備ができたら「適用」をクリックします。デフォルトでは、コンポジットはドメイン・レベルの遅延ロード設定を継承します。この動作を特定のコンポジット・レベルで制御するユースケースがある場合、composite.xmlで構成することができ、これは新しいSOA Suiteコンポジット・アプリケーションを作成したときに生成されるファイルです。
編集するアプリケーションのホーム・フォルダにcomposite.xmlがあります。また、JDeveloperでアクセスすることでcomposite.xmlを編集できます。composite.xmlの詳細は、Oracle Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発で、SOAアプリケーションおよびプロジェクトを作成した場合の処理に関する項を参照してください。
編集するアプリケーションのcomposite.xmlの先頭に新しいプロパティlazyLoading="false"を追加して、ドメイン・レベルでのデフォルトの動作をオーバーライドする必要があります。その後コンポジットをデプロイします。
サンプル・コード・スニペットを次に示します。
<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 12.2.1.0.0 at [8/7/13 4:14 PM]. -->
<composite name="ValidatePayment"
revision="1.0"
label="2013-08-07_16-14-11_843"
mode="active"
state="on"
lazyLoading="false"
xmlns="http://xmlns.oracle.com/sca/1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
……….
……….
</composite>
モジュール性は、メモリー・フットプリントおよびサーバー起動時間の改善に役立つもう1つの12c機能です。プロファイル・オプションの一部は、選択したコンポジットによって使用されるコンポーネントおよび機能のみに制限されています。選択したモジュール性プロファイルによって、メモリーにロードされるコンポーネントが決定されます。
12cには、インストール完了後に変更できる即時利用可能なプロファイルが付属しています。デフォルトで、新規の12c顧客には、インストール・プロファイルとしてSOA_FOUNDATIONがあります。12cにアップグレードする既存の顧客には、デフォルトでインストール・プロファイルとしてSOA_CLASSICがあります。
表11-3に、メモリー・フットプリント・サイズが増加する順にモジュール性プロファイルを示します。
表11-3 モジュール性プロファイル
| プロファイル | コンポーネント |
|---|---|
|
BPELコンポーネント + SOA共通インフラストラクチャ + 部分アダプタ・セット |
|
BPELのみ + HWF + 部分アダプタ・セット |
新規12c顧客のデフォルト |
Orchestration + Mediator + Rules + 部分アダプタ・セット |
|
SOA Foundation + 完全アダプタ・セット |
|
SOA Foundation Enterprise + B2B |
|
SOA Foundation with B2B + Healthcare UI |
アップグレード顧客のデフォルト |
SOA Foundation with B2B + BPMモジュール |
SOA Suiteで制限されたコンポーネントまたは機能のセットを使用している場合、プロファイルを変更してメモリー使用率およびサーバー起動時間を最適化できます。これによって重要なプロセス用にリソースを解放し、障害回復を改善できます。
モジュール性プロファイルは、Fusion Middleware ControlのEnterprise ManagerのSOAダッシュボードから変更できます。
プロファイルの変更方法の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理でSOAインフラストラクチャの共通プロパティに関する項を参照して、「SOAインフラストラクチャの共通プロパティ」ページを探してください。
次にプロファイルの詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理のOracle SOA SuiteおよびOracle BPM Suiteプロファイルの構成に関する項を参照してください。
必要に応じて、データベースをSOAプロセス用にチューニングするための高度な戦略を採用します。先に進む前にこのドキュメントのデータベース・パラメータのチューニングに記載されている一般的なデータベース・チューニング提案を参照して従っていることを確認してください。
オプティマイザ統計により、データベースとデータベース・オブジェクトに関する詳細が提供されます。問合せオプティマイザは、これらの統計を使用して各SQL文に最適な実行計画を選択します。詳細は、『Oracle Database SQLチューニング・ガイド』の問合せオプティマイザの概要に関する項を参照してください。
データベース内のオブジェクトは絶えず変化するため、オブジェクトを正確に表すには統計を定期的に更新する必要があります。
すべてのSOAデータベースでは、自動統計収集を使用する必要があります。これはデフォルトで有効化されています。このジョブは毎晩実行されます。詳細は、『Oracle Database SQLチューニング・ガイド』の自動オプティマイザ統計収集の制御に関する項を参照してください。
自動オプティマイザ統計収集は大半のデータベース・オブジェクトで十分ですが、動作中に近いデータベースや、大幅に変更されたりパージされた表では、手動統計収集が必要です。詳細は、『Oracle Database SQLチューニング・ガイド』のオプティマイザ統計の手動収集に関する項を参照してください。
失効データを定期的にパージするSOAデータベースでは、パージ完了直後に統計を手動で収集する必要があります。これらの場合、DBMS_STATS.GATHER_TABLE_STATSプロシージャを使用します。この方法の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスのDBMS_STATSに関する項を参照してください。
この項に進む前に、TEMP表領域をOracle Fusion Middleware用にチューニングするための一般的なガイドラインについて、データベース・ファイルのチューニングを参照してください。
一部のSOA問合せでは大容量のディスク・ソートが生成される場合があり、大容量の一時表領域が必要になります。そのため、複数の一時表領域と表領域グループを使用して、これらの要件に適合させ、最適なパフォーマンスを確保することをお薦めします。
SOAスキーマ所有者に割り当てられる一時表領域グループまたはTEMP表領域の最小提案サイズは、自動拡張が有効な状態で6GBです。表領域をサイズ変更し自動拡張を有効にする方法の詳細は、Oracle Database管理者ガイドのデータ・ファイル・サイズの変更に関する項を参照してください。
大半のSOAワークロードでは高い負荷のDMLアクティビティがデータベースで生成され、競合がデータベース・オブジェクトで発生する可能性があります。
自動ワークロード・リポジトリ(AWR)レポートの待機イベント・データにより、パフォーマンスに影響する場合がある様々な症状が明らかになります。SOAデータベースで発生する場合がある最多発待機イベントは、次のとおりです。
DB CPU
Db file sequential read、db file scattered read
log file sync
enq: HW - contention
enq:TX-indexcontention
buffer busy waits
gc buffer busy acquire、gc buffer busy release (RAC)
enq: SQ - contention
SOAデータベースでは、長い平均待機時間のフォアグラウンド待機イベントlog file syncが発生することがごく普通です。これはREDOログ・パフォーマンスにより発生します。長いlog file sync待機では次のような原因が考えられます。
データベースのログ・ライター(LGWR)では、次のいずれかの原因で高速に書込みを完了できません。
ログ・ファイルのディスクI/Oパフォーマンスは十分ではありません。
LGWRではCPUリソースが不足しています。
LGWRでは、過剰なコミットにより十分高速にプロセスをポストできません。
LGWRでは他のデータベース競合(エンキュー待機やラッチ競合など)が発生しています。
REDOログのパフォーマンスをチューニングすると、Oracle Fusion Middleware環境で実行するアプリケーションのパフォーマンスを向上できます。
この項に記載の戦略を使用してSOAプロセス用にチューニングする前に、REDOログをOracle Fusion Middleware用にチューニングするための一般的なガイドラインについて、データベース・ファイルのチューニングを参照してください。
LGWR待機イベントの検索
根本原因を識別する最初の手順では、LGWR待機イベントを探して分析します。次の例に示すように、SIDを使用して、LGWR待機イベントを問い合せます。
SQL> SELECT sid, event, time_waited, time_waited_micro
FROM v$session_event
WHERE sid IN
(SELECT SID FROM v$session WHERE type!='USER' AND program LIKE '%LGWR%' )
ORDER BY time_waited;
ログ切替えの頻度を制御しシステム待機を最小化するようにオンラインREDOログのサイズ設定
REDOログの最小提案設定は、それぞれ2GBのログ・グループを3つ以上保持することです。REDOログのパフォーマンスを定期的に監視します。そして、ログ切替えの頻度を制御してシステム待機を最小化するために、REDOログ・グループの数と各メンバーのサイズを適切に調整します。
システムが生成するREDOの量に従って、REDOログ・ファイルをサイズ設定します。大まかなガイドラインとしては、20分ごとに最大1回ログを切り替えます。
たとえば、データベース・アクティビティのピーク時にオンラインREDOログを5分ごとに1回切り替える場合、20分ガイドラインを実現するには、ログはそれぞれ現在のサイズよりも4倍大きくする必要があります。この計算方法は、20分/5分=4xです。
ボトルネック防止のためのREDOログ・ディスクの最適化
SOAデータベースは高い書込み集中型で、トランザクションごとに1秒当たり過大な量のREDOが生成されます。ディスクをチューニングしていなくてもREDOログ・ボトルネックが軽減される場合があります。Oracleではすべての更新をすべてのディスクで単一のREDO場所に書き込む必要があるからです。
I/O帯域幅が問題の場合、I/O帯域幅を改善する処置以外を行っても有用ではありません。REDOボトルネックを軽減する方法の1つは、高速なREDO記憶域を使用することです。ソリッド・ステート・デバイス(SSD)のREDOログ・ファイルを使用することをお薦めします。SSDは円盤ディスクよりも帯域幅が広いです。
log_bufferの最適サイズ設定の決定
SOAアプリケーションでは大量のデータの挿入、変更および削除が行われます。これらの操作の大半は、バッチ・モードではなく行単位の方法でコミットされます。頻繁にコミットすると、大幅なオーバーヘッドがREDOパフォーマンスで発生するので、log_bufferのサイズを最適に設定することはパフォーマンスで重要になります。
AWRレポートまたはV$ビュー(あるいはその両方)からのREDO BUFFER ALLOCATION RETRIES統計では、ユーザー・プロセスがREDOログ・バッファ内の領域の使用を待機した回数を反映します。次の問合せで動的パフォーマンス・ビューのV$SYSSTATによりこの統計を取得できます。
SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo buffer allocation retries';
redo buffer allocation retriesの値は、ある時間間隔に対して0(ゼロ)に近い値である必要があります。この値が一貫して増分する場合は、プロセスがREDOログ・バッファ内の領域を待機する必要があったということです。この待機は、ログ・バッファが小さすぎること、あるいはチェックポイント機能が原因となっていることがあります。次を試行することでこの待機を改善できます。
必要であれば、初期化パラメータのLOG_BUFFERの値を変更することによって、REDOログ・バッファのサイズを大きくできます。このパラメータの値はバイト単位で表されます。書込み集中型ワークロードにおける経験則としてはまず、ログ・バッファを100MBに構成することです。log_buffer設定の値を大きくする際は注意してください。過大なREDOサイズによって長時間のlog file sync待機が発生する可能性もあります。
チェックポイント機能またはアーカイブ・プロセスを改善します。
また、log buffer space待機イベントがインスタンスの待機時間における重要な要因であるかどうかもチェックできます。そうでない場合、ログ・バッファ・サイズが適切である可能性が高いです。
LGWRプロセスのチューニング
ほとんどのSOAワークロードでは、コミット率が非常に高く、コミットを減らすことはオプションではありません。前の戦略で長時間のlog file syncに対処してもREDOログのパフォーマンスが向上しない場合、コマンド・ラインからLGWRの優先度クラスをRTに高くしたり、LGWRの優先度を高くします。
ExaData用スマート・フラッシュ・ロギングの使用
データベースがExaDataマシンにある場合、スマート・フラッシュ・ロギング機能を活用するためには、少なくともバンドル・パッチ11 (BP11)がインストールされている必要があります。
Exadataスマート・フラッシュ・ロギングは、データベース・バージョン11.2.0.2 + BP11とExadata Storageソフトウェア11.2.2.4.2で実装された追加機能です。この機能により、512MBのフラッシュ記憶域がREDO書込み用に予約され、異なるパターンの動作がLGRWプロセスで採用されます。
この機能を使用しないシステムでは、LGWRではREDOログの多重化コピーに並列して書込みを行い、すべての書込みが完了するのを待機します。これらの書込みの実行に要する時間(Oracle待機インタフェース統計ログ・ファイル・パラレル書込みで示される)は、最も低速なディスクが書込みを完了するのに要する時間であることをこれは意味します。
Exadataスマート・フラッシュ・ロギングでは、REDOログ・ファイルはディスクに残りますが、512MBの予約領域が別にフラッシュ記憶域に作成されます。書込みコールが発行されると、LGWRではREDOログをディスクに通常どおりに書き込みますが、フラッシュ領域への並列書込みも行います。そして、他方を待機せずに続行した後に、LGWRではこれらの書込みのどれかが最初にポストを完了するのを待機します。
競合プロセスが同じ表に挿入して、表の最高水位標を同時に増加させようとすると、最高水位エンキュー競合(enq:HW - contention)が発生します。
SOAデータベースでは、ラージ・オブジェクト(LOB)列(CUBE_SCOPE、XML_DOCUMENT、AUDIT_DETAILSなど)のある表でこの問題が発生します。負荷が高くなると、これらの表のLOBセグメントでは競合が発生し、AWRレポートで待機イベントのenq: HW contentionとして表示されます。
OracleデータベースにおけるLOBのデフォルト記憶域はBasicFileです。頻繁にエクステントを割り当てたりチャンクを再利用すると、LOBセグメントの最高水位標で競合が発生する場合があります。また、ASSMが管理するLOBセグメントでこの競合が発生する場合があります。領域割当てでは一度に1つのブロックのみ取得するからです。
LOB記憶域をBasicFileからSecureFileに切り替えることで、この競合を解消できます。SecureFileは、従来のBasicFileに比べてパフォーマンス上の利点があるLOB記憶域アーキテクチャです。これらの2つのアーキテクチャの詳細は、『データベースSecureFilesおよびラージ・オブジェクト開発者ガイド』のLOB記憶域に関する項を参照してください。
次のいずれかの方法を使用すると、BasicFileをSecureFileに移行できます。
データベース・パラメータSECURE_FILES = ALWAYSを設定します。
RCUを使用してSOA表を作成する前に新規インストールでこの方法が適用できます。このパラメータがインスタンス・レベルで設定されると、作成された新規LOBセグメントではSecureFileを自動的に使用します。
オンライン再定義方法を使用します。
SOA表が作成されているインストールでこの方法が適用できます。このような場合、enq: HW contentionが発生しているSOAデータベースにある表からLOBセグメントをSecureFileに移行できます。
オンライン再定義方法を使用してSecureFileに移行でき、停止時間はほとんどありません。
次のスクリプトを使用してデータベース・イベント値を44951に設定します。
ALTER SYSTEM SET EVENT='44951 TRACE NAME CONTEXT FOREVER, LEVEL 1024? scope=spfile;
この方法により、11gよりも古いOracleバージョンを使用するSOAインストールでenq:HW contentionsをLOBセグメントで防止するのを支援します。
AWRと自動データベース診断モニター(ADDM)のレポートを使用して、enq:HW - contentionsで影響を受けるLOBオブジェクトを識別できます。ただし、ほとんどのシステムでは、次の表に記載されているLOB列をSecureFileに移動することを強くお薦めします。
| 表名 | 列名 | 推奨LOB記憶域アーキテクチャ |
|---|---|---|
|
|
|
|
|
|
|
|
|
ほとんどのSOAシナリオでは、複数のデータベース・セッションにより何千もの行がSOA表に挿入されます。これらの状況では、索引キー(特に主キー索引)の数は絶えず増加します。
主キー索引の数が時間の経過により増加しても、Bツリー構造索引がキー挿入で少数のデータベース・ブロックのみをターゲットにします。これらのBツリー索引挿入がReal Application Cluster (RAC)で問題になる場合があります。この問題は、AWRレポートには高いbuffer busy waitsとして表示されます。
Bツリー索引により、RAC環境で他の競合が生成され、gc buffer busy acquireとgc buffer busy releaseの待機イベントとしてAWRに表示されます。索引に行を挿入するトランザクションが、他のトランザクションによる索引ブロック分割の終了を待つ必要ある場合、これらが発生し、同様にセッションが強制的に待機します。多くの同時挿入により過剰な索引ブロック分割が行われると、パフォーマンスが低下します。
これらの競合の解決策は、グローバルでハッシュのパーティション化索引を作成することです。これによって多くのデータベース・ブロックにおいて索引キーを強制的にランダムに分散して、これらの競合やホット・スポットを防止します。
ハッシュ・パーティション化は、索引競合に対処する最善のチューニング方法であることが立証されています。AWRとADDMのレポートを使用して、パーティション化が必要な索引を識別する必要があります。ホット索引を識別したら、ハッシュ・パーティション化を検討し、索引競合を削減するか予防します。
積極的で継続的なパージの必要性は、パフォーマンスを改善しディスク領域をSOAで制御する重要な要因です。
自動パージ機能の管理がデフォルトで有効にされ、12cで進行中のデータベース増大の管理に役立ちますが、この機能が表11-2に記載されています。また、大量のデータが蓄積されるSOAインストールでは、パージ戦略を実装して、冗長なデータをクリーンアップし、SQL問合せパフォーマンスを支援して, ディスク領域を節約する必要があります。
パージ戦略を作成するには、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、パージとパーティション化方法の開発に関する項を参照してください。
不要なデータをSOA表から頻繁にパージするSOAインストールは、ディスク領域問題が発生する可能性が高いです。
ASSMとローカル管理表領域でもこの問題が発生します。自動パージ・スクリプトで行をデータベースの表と索引から削除して、再利用できるようにデータブロック内の領域を解放しても、行が削除された直後に領域は解放されません。特に表にLOB列がある場合。これによって、断片化が発生し、領域が過小で再利用できません。
断片化を軽減してディスク領域を統合するには、表とLOB列を手動で小さくして、定期的に領域を解放する必要があります。
オンラインによるセグメントの縮小で利点を得られるセグメントを特定するには、セグメント・アドバイザを使用します。ただし、定期パージ後はSOAセグメントの大半がオンラインのセグメント縮小操作の候補になります。セグメント・アドバイザの使用方法の詳細は、Oracle Database管理者ガイドのセグメント・アドバイザの使用に関する項を参照してください。
縮小が必要なデータベース表と索引を識別したら、次のコマンドを使用して、領域を手動で解放します。
ALTER TABLE CUBE_SCOPE ENABLE ROW MOVEMENT; ALTER TABLE CUBE_SCOPE SHRINK SPACE; ALTER TABLE CUBE_SCOPE MODIFY LOB (SCOPE_BIN) (SHRINK SPACE); ALTER TABLE CUBE_SCOPE DISABLE ROW MOVEMENT;
この縮小操作によって、最高水位標を下回る空き領域が統合され、セグメントが圧縮されます。そして、最高水位標が移動し、最高水位標の上で領域が割当て解除されます。
イベント配信ネットワーク(EDN)は、Oracle Mediator、Oracle BPEL Process Manager、およびOracle Application Development Frameworkエンティティ・オブジェクトなどの外部パブリッシャによってパブリッシュされたイベントを配信します。詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、イベント配信ネットワークおよびJMSプロバイダ・タイプの概要に関する項を参照してください。
表11-4に、Fusion Middleware MBeanブラウザで検索してイベント配信を改善するためにチューニングできるパラメータを示します。
表11-4 イベント配信ネットワークのチューニング
| パラメータ | 問題点 | チューニングに関する推奨事項 | トレードオフ |
|---|---|---|---|
デフォルト: -1 |
|
デフォルト値の-1は、システムが ただし、多数のサブスクライバがある場合、デフォルト設定では各サブスクライバに対するスレッドの割当てが試行されます。これによってシステムが遅くなります。このタスクに作成されるポーラー・スレッドの数を制限するには、正の整数を定義する必要があります。 このパラメータの値をFusion Middleware MBeanブラウザで変更する方法は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、サービス・コンポーネント・レベルでのローカルのnumberOfPollerThreads値の更新に関する項を参照してください。 |
値がシステムに対して小さすぎる場合、ポーラー・スレッドによってイベント・バックログが発生し、イベント・パブリッシュとコンポジット・インスタンス作成の間の待機時間が長くなる可能性があります。 値が大きすぎる場合は、余分なポーラー・スレッドがサーバー・リソースを不必要に消費します。 |
デフォルト: 1スレッド |
|
一般的に、スクライバごとに1スレッドというデフォルトは最適です。 パラメータ このパラメータの値をFusion Middleware MBeanブラウザで変更する方法は、Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、システムMBeanブラウザでのThreadsPerSubscriber属性の更新に関する項を参照してください。 |
値がシステムに対して小さすぎる場合、ポーラー・スレッドによってイベント・バックログが発生し、イベント・パブリッシュとコンポジット・インスタンス作成の間の待機時間が長くなる可能性があります。 値が大きすぎる場合は、余分なポーラー・スレッドがサーバー・リソースを不必要に消費します。 |
表11-5に、JDeveloperで個別のビジネス・イベントに対して変更できるパラメータを示します。これらの属性を変更するには、編集するイベントを右クリックしてポップアップ・メニューを出します。このメニューから、編集するパラメータに応じて「サブスクライブ済イベントの編集...」または「パブリッシュ済イベントの編集...」を選択します。
編集できるサブスクライブ済イベント・パラメータの詳細は、Oracle Fusion Middleware Oracle SOA SuiteでのSOAアプリケーションの開発で、ビジネス・イベントのサブスクライブ方法に関する項を参照してください。
表11-5 ビジネス・イベントのチューニング
| パラメータ | 問題点 | チューニングに関する推奨事項 | トレードオフ |
|---|---|---|---|
サブスクライブ済イベントの一貫性 デフォルト: |
ビジネス・イベント配信で次のいずれかまたは両方の問題が発生しています。
|
JDeveloperで選択したビジネス・イベントのレベルを Oracle Enterprise Manager Fusion Middleware Controlのサブスクリプション・ページでこのパラメータを編集できます。詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、ビジネス・イベント・サブスクライバの表示に関する項を参照してください。 |
|
サブスクライブ済イベントの永続性 デフォルト: |
ビジネス・イベント・メッセージで次のいずれかまたは両方の問題が発生しています。
|
JDeveloperで、 |
|
パブリッシュ済イベントの永続配信 デフォルト: |
|
この値を |
|
パブリッシュ済イベントの存続時間 デフォルト: 0ミリ秒 |
|
期限切れメッセージがシステムから自動的に削除されてサブスクライバによって消費されないように、正の整数を指定します。整数はミリ秒を表します。 最善の値はシステムによって異なり、モニタリング・メトリックによって決定できます。 デフォルト値の0はメッセージが期限切れにならないことを意味します。 |
メッセージ有効期間の値が小さすぎると、パブリッシュ済のメッセージが対象のサブスクライバによって読み取られる前に期限切れになることがあります。一度削除されると取得できません。 値が大きすぎる場合は、残っているメッセージがシステム・リソースを占有することがあります。 |
デフォルトでは、すべてのイベントが単一のWLSトピックにマップされます。
JMSトピックが1つまたは制限されているためにイベントのバックログが大量にある場合や、イベント処理に待機時間が発生したり処理の速度が遅い場合、追加のJMSトピックを作成してJMSマッピングへのイベントを変更し、異なるパフォーマンス特性のイベント・タイプが別々にグループ化または管理されるようにする必要があります。
ただし、このようにすると、システムが管理するJMSトピックおよびJMSアーティファクトが追加されて、マッピング変更を考慮する必要があります。
WLSJMSトピックまたはAQJMSトピックのいずれかを作成できます。
WLSJMSはデフォルトのJMSトピック・タイプです。AQJMSと同様に、データベース索引付け、LOBストリーミング、埋込みルール・エンジンおよびロック管理は提供されません。
AQJMSは一般的にWLSJMSよりも高速ではありませんが、シングルスレッドであるため、システムのオカレンス数が多い場合はAQJMSが適切に機能します。AQJMSはまた、Exalogicの記憶域ノード数を少なくすることによって制限できます。
管理者としてログインしている場合、WebLogic管理コンソールのSOAJMSModuleの下に新規のWLSJMSトピックを作成できます。「新しいJMSシステム・モジュール・リソースの作成」に移動してJMSトピックを作成する方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプで、システム・モジュールでのトピックの作成に関する項を参照してください。
JDeveloperまたはSQL Developerでデータベース・ナビゲータを使用して、soainfraユーザーとして次のスクリプトを実行することによって、AQJMSトピックを作成できます。
define edn_user=your_soainfra_schema_username define topic=your_custom_aqjms_topic_name, e.g. 'EDN_AQJMS_TOPIC_2' define topic_table=your_custom_aqjms_topic_table, e.g. 'EDN_AQJMS_TOPIC_TABLE_2' begin DBMS_AQADM.stop_queue(queue_name => '&edn_user..&topic'); DBMS_AQADM.drop_queue(queue_name => '&edn_user..&topic'); DBMS_AQADM.drop_queue_table(queue_table => '&edn_user..&topic_table'); end; / begin dbms_aqadm.create_queue_table(queue_table => '&edn_user..&topic_table', queue_payload_type => 'SYS.AQ$_JMS_MESSAGE', multiple_consumers => true); dbms_aqadm.create_queue(queue_name => '&edn_user..&topic', queue_table => '&edn_user..&topic_table', max_retries => 256); dbms_aqadm.start_queue(queue_name => '&edn_user..&topic'); end; / commit;
AQ JMSトピックの詳細は、Oracle Fusion Middleware Oracle WebLogic Server JMSリソースの管理のJMSキューまたはトピックの作成に関する項を参照してください。
新規のJMSトピックを作成すると、ビジネス・イベントを特定のトピックにマップできます。1つのイベント・タイプは1つのJMSトピックにのみマップできますが、1つのJMSトピックは複数のイベント・タイプを格納できることに注意してください。
Fusion Middleware ControlのEnterprise Managerを使用してイベントをマップする方法の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理の「ビジネス・イベント」ページでのJMSトピック宛先へのビジネス・イベントのマッピングに関する項を参照してください。
SOAインフラストラクチャのパフォーマンスは、WebLogic Serverに依存します。WebLogic Serverのチューニングは別のタスクでありこのマニュアルでは詳細に説明していませんが、表11-6を使用して、SOAインフラストラクチャに影響を与えるチューニング・ノブを確認できます。
表11-6 SOAインフラストラクチャに対する重要なWebLogic Serverのチューニング
| パラメータ | チューニングに関する推奨事項 | リソース |
|---|---|---|
デフォルト: ドメイン作成中に設定したモード。 |
本番モードがパフォーマンスを最大化します。アプリケーションを開発中でない場合は、これを有効にする必要があります。Oracle Fusion Middleware Controlで |
Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理で、一般設定の構成に関する項を参照してください。 ドメイン・モードを変更すると、特定のセキュリティ設定および自動デプロイメント設定も変更されます。ドメイン・モードの詳細は、Oracle Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニングで、開発モードと本番モードのデフォルトのチューニング値に関する項を参照してください。 |
WebLogic Serverのロギング・レベル デフォルト: |
ログ記録リクエストの量を減らすために、可能なかぎり |
これらの方法の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリングで、ログ重大度レベルの使用に関する項を参照してください。 |
HTTPアクセス・ロギング デフォルト: 有効 |
デフォルトでは、HTTPサブシステムはすべてのHTTPトランザクションのログをテキスト・ファイルに保存します。パフォーマンスを改善するには、HTTPアクセス・ロギングをオフにします。Oracle WebLogic Server管理コンソールを使用してこのプロパティを無効にできます。 |
Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプのHTTPログの有効化と構成に関する項を参照してください。 |
JMS永続性および永続記憶域 デフォルト: |
適切な永続性レベルがJava Message Service (JMS)の宛先に設定されていることを確認します。
|
永続的なJMSストアの作成および管理の詳細は、Oracle Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニングで、カスタム・ファイル・ストアおよびJDBCストアの使用に関する項を参照してください。 |
接続バックログのバッファリング |
多くの同時クライアントを処理する場合には、
|
詳細は、Oracle Fusion Middleware Oracle WebLogic Serverのパフォーマンスのチューニングの接続バックログのバッファリングのチューニングに関する項を参照してください。 |
ワーク・マネージャはSOAプロジェクトおよび特定のコンポーネントにマップされ、いくつかの高度な構成オプションを使用してワーク・マネージャのパフォーマンスを細かくチューニングできます。
SOA Suiteがインストールされると、SOAインフラストラクチャの様々な領域を管理するために、デフォルトのワーク・マネージャ、グローバル・ワーク・マネージャおよびアプリケーション・ワーク・マネージャのセットを作成します。
優先度が高いコンポジットには、高い優先度用に構成されたワーク・マネージャ・グループを関連付けることができます。表11-7に、SOAのインストール時に作成されるワーク・マネージャのセットを示し、それらが管理する作業領域を説明します。
表11-7 ワーク・マネージャの説明
| ワーク・マネージャ名 | 担当する領域 |
|---|---|
|
次のようなSOA同期リクエスト・クライアント:
|
|
すべてのSOA通知リクエスト。 |
|
BPEL固有のシステム・ディスパッチャ・メッセージ。 |
|
BPEL固有のエンジン・プロセス呼出しディスパッチャ・メッセージ |
|
BPELエンジン・プロセス・ディスパッチャ・メッセージ |
|
BPELエンジン・プロセス非ブロッキング呼出しディスパッチャ・メッセージ |
|
BPEL分析 |
|
メディエータ・パラレル・ルーティング |
|
メディエータのエラー処理 |
|
BPMシステム・ディスパッチャ・メッセージ |
|
BPMエンジン・プロセス呼出しディスパッチャ・メッセージ |
|
BPMプロセス・エンジン・ディスパッチャ・メッセージ |
|
BPMプロセス非ブロッキング呼出しディスパッチャ・メッセージ |
|
ワークフローEnterprise JavaBeans (EJB)を含む、 |
|
|
|
イベント配信ネットワーク(EDN) |
|
アダプタ・フレームワーク |
SOAMaxThreadsConfig属性でのワーク・マネージャの構成に説明されているSOAMaxThreadsConfigプロパティは、ワーク・マネージャが受信リクエスト、内部プロセスおよびその他のプロセスの処理に使用する接続の数を決定します。この構成によって、システムが最大の可能性で機能しているときの、これらの各処理カテゴリの最適な使用率が決定されます。
また、最小および最大の制約をワーク・マネージャで設定して、ワーク・マネージャの接続の上限および下限を制御できます。ワーク・マネージャに割り当てられる相対的な優先度を決定するために、ワーク・マネージャのフェア・シェア・リクエスト・クラスを作成できます。ここで説明する制約およびリクエスト・クラスは、SOAワーク・マネージャで最も一般的に構成されているものです。
すべてのSOAワーク・マネージャには、最も有用なリクエスト・クラスおよび制約が事前に構成されています。デフォルトの設定で実行して、評価期間の後に重要な変更を行うことをお薦めします。
作成できるすべてのワーク・マネージャの制約およびリクエスト・クラス、およびそれらのデフォルトの動作の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、ワーク・マネージャ・グループの管理に関する項を参照してください。
フェア・シェア・リクエスト・クラスを使用すると、指定されているワーク・マネージャの相対的な優先度を指定できます。内部プロセスを管理するすべてのSOAワーク・マネージャは、デフォルトでそれぞれフェア・シェア値を20と80に設定して作成された2つのフェア・シェア・クラス(soa_fairShare_20およびsoa_fairShare_80)のいずれかに構成されています。フェア・シェア値は1から1000の相対値です。
SOAワーク・マネージャの優先度をさらにチューニングする場合、新しいフェア・シェア・クラスを作成する必要があります。この方法の詳細は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、ワーク・マネージャ・グループの表示および作成に関する項を参照してください。
SOAMaxThreadConfigで使用可能なデフォルトのカテゴリに加えて、特定のシナリオに対処する新しいカテゴリを作成できます。
SOAのプロセスには、データベース接続が不要なものもあります。このようなプロセスはSOAデータ・ソースの割当てに依存せず、使用可能な接続を待機する必要がありません。
SOAインフラストラクチャは、ほとんどのプロセスを管理して適切にリソースを割り当てるワーク・マネージャを自動的に作成します。ほとんどの場合、既存のワーク・マネージャを利用して、前述のノブのいくつかを使用してそれらのパフォーマンスをチューニングすることによって、パフォーマンスを改善できます。
独自に処理する必要がある特別なシナリオがある場合は、新しいワーク・マネージャを作成して、特別な状況に合うようにそれを構成できます。新しいアプリケーションまたはWebアプリケーションのワーク・マネージャのいずれかを作成します。詳細な手順は、Oracle Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理で、ワーク・マネージャ・グループの表示および作成を参照してください。
