| Oracle® Fusion Middlewareテクノロジ・アダプタの理解 12c (12.2.1) E69958-02 |
|
 前 |
 次 |
アダプタのリストは、次のとおりです。
各項には、一般的なフレームワークまたは特定のアダプタに関連した各チューニング・ガイド・パラメータについて、次の内容が示されます。
プラクティスまたはパラメータの一般的な説明。
適切にチューニングされていない場合の症状: このパラメータまたはプラクティスに関連するチューニングが不適切な場合、どのような症状が発生するか。
チューニングのデメリット: これらのパラメータおよびプラクティスに関連して、どのような問題に注意する必要があるか。
症状が発生した場合の対処: パフォーマンスを改善するために、パラメータまたはプラクティスをどのように調整するか。
Oracle JCAアダプタ・フレームワークの最も重要なプラクティスおよびパラメータは、次のとおりです。
このパラメータは、データを消費する際にJCAアダプタが許容する最大サイズ(バイト単位)を制御します。つまり、エンドポイントのポーリング中に非同期的に受信するか(JCAサービス)、JCA参照を使用して同期的に読み取るかを制御します。
消費する(ネイティブ)メッセージのサイズが構成済のpayloadSizeThreshold (SCAサービスまたは参照ベースで構成)を上回る場合、メッセージは拒否されます。
Oracle XDK XMLへのネイティブ・メッセージを解析する場合、メッセージにはネイティブ・メッセージが使用する10から15倍のメモリー量が必要です。たとえば、サイズが1MBのファイル・システム内のフラット・ファイルは、JVMヒープでは(DOMとして)10から15MBを消費します。
このプロパティのデフォルト値は-1で、無制限を意味します。
Fusion Middleware Controlを使用して設定可能なグローバルのpayloadSizeThreshold が(AdapterConfigMBeanに)あり、payloadSizeThresholdに対して特定の値が明示的に構成されていないすべてのJCAエンドポイントのデフォルトの制限となります。
つまり、エンドポイント設定は常にグローバル設定よりも優先されます。
この設定は一般的に、予測されるメッセージ・サイズについて疑いがある場合に構成する必要があります。
消費されるメッセージをアプリケーション自体が生成している場合、このアプリケーションについて、このプロパティを構成する必要性が減少すると想定できます。
このプロパティの目的は、受信アダプタ・メッセージに使用されるJVMヒープ・スペースの量を制限することです。値は、同期または非同期のビジネス・フロー内で(少なくとも)次のファクタから影響を受けます。
同期フロー。消費される各インバウンド・メッセージは、同期インスタンスの実行中、長い間JVMヒープにとどまる必要があります。アダプタ・ポーリング・スレッドの数によって、同時にJVMに存在するメッセージ・インスタンスの数が特定されます。ポーリング・スレッドが多いほど、payloadSizeThresholdは小さくなります。
非同期フロー。インバウンド・メッセージは、アダプタが受信メッセージを読み取って変換する間、および最初のダウンストリーム・サービス・エンジンがメッセージを受信して保持するまでの短い期間、ヒープに存在します。ただし、これらのダウンストリーム・サービス・エンジンのスレッド・モデル(BPELワーカー・スレッドなど)によって、ヒープに同時に存在できるインスタンスの数が決定され、これに応じて妥当なpayloadSizeThreshold値を考慮する必要があります。
ストリーミングが有効な場合、つまりアダプタがSDOM (スケーラブルなDOM)インスタンスを生成している場合、Oracle XDKはページング・ストレージにほとんどのXMLを維持するため、より大きい値をpayloadSizeThresholdに使用できます。これは、インスタンスで実行されるXpath、XsltおよびXQueryで使用するDOMアクセス・パターンに依存します。
SDOMインスタンスで使用されるメモリーがどれだけ少なくなるかはビジネス・ロジックに大きく依存するため、実験的なテスト・データがこのパラメータの設定に役立ちます。
この使用例は、ビジネス・ロジックによってアダプタが起動され、同期読取り操作(ファイルの読取りまたは表からのデータの選択)が実行される状況を示しています。たとえば、SQL選択操作によって非常に多くの(ネストされた)行が戻されるリスクがある場合は、payloadSizeThresholdに妥当な値を設定することをお薦めします。サイズが超過している場合は、ビジネス・フォルトがスローされ、ビジネス・ロジックによって補完的なアクションが決定され、自動的には拒否されません。
矛盾する次の懸念事項のバランスを保つ、よく考慮されたpayloadSizeThresholdの値を選択する必要があります。
JVMヒープがサイズの大きすぎるメッセージであふれないようにすること。
多くのメッセージが拒否される問題。
つまり、個別のインバウンド・メッセージで多くのポーリング・スレッドまたは処理スレッドが並行して動作できる場合、値をデフォルトの-1 (無制限)のままにしたり非常に大きくすると、JVMが使用可能なヒープ・スペースを使い果たしたときに致命的な実行時エラーが発生する可能性があります。
値を小さく設定すると非常に多くのメッセージが拒否され、これにより通常のビジネス・フローが不必要に混乱し、メッセージが許容可能なサイズであってもリカバリをスケジュールするか、または手動でリカバリする必要があります。
ネイティブ・メッセージのサイズ計算にかかるコストは、このプロパティの構成における潜在的なデメリットです。しきい値を設定すると、特にデータベース・アダプタの場合に重大なパフォーマンス上の影響が生じる可能性があります。
メモリー不足(OOM)エラーがSOAで発生し始めたことがログに示されている、全体的なシステムの速度低下が検出される、ガベージ・コレクションが頻繁に発生し始めたなどの症状が発生したときに、これらの症状を、サイズ超過のネイティブ・アダプタ・メッセージのインフローに関連付けることができる場合は、メッセージのしきい値をすぐに設定する必要があります。
新しいしきい値を動的に設定するには、グローバルに変更するために(すべてのエンドポイントに適用される)構成MBeanを使用するか、または1つ以上のインバウンドJCAエンドポイント(非常に大きなメッセージを受信すると考えられるエンドポイント)のバインディング・プロパティpayloadSizeThresholdを変更できます。
minimumDelayBetweenMessagesは、アダプタ・ポーリング・スレッドの実行を遅延させるための単純なメカニズムです。
小さなスレッド・スリープをインスタンス実行の一部として、ポーリング・スレッド・ベースで追加します。設定はミリ秒で測定されます。遅延は、次のダウンストリーム・コンポーネントが起動する直前に追加されます。
アダプタがポーラー・スレッドの一部としてトランザクションを開始する場合、トランザクション・タイムアウトは、最悪な場合の許容可能なインスタンス実行の最大値とminimumDelayBetweenMessagesの値に対応する必要があります。
インスタンス実行自体(2つの最新メッセージのパブリッシュの間の時間)がminimumDelayBetweenMessagesの値を超える場合、遅延は追加されません(そのため、名前はminimumDelay...になります)。
構成されていない場合、インバウンドJCAアダプタのエンドポイントからのメッセージ間に遅延はありません。
ビジネス・プロセスに非同期の構造/署名がある場合、(メッセージがディスパッチャ・キューに溜まっている)アダプタ・エンドポイントから届くインバウンド・メッセージの速度に対応できなければ、この状況ではダウンストリームのビジネス・ロジックのオーバーロードが生じる可能性があります。
または、ビジネス・プロセス・フローが同期の場合、ポスティング・アダプタ・ポーリング・スレッドは、前のメッセージのインスタンス実行が完了するより前に新しい受信メッセージを再取得しません(これは最初のダウンストリーム・デハイドレーション・ポイントまでの範囲にのみ関連します)。
ただし、minimumDelayBetweenMessagesに大きい値を構成すると、ダウンストリームのビジネス・プロセスが不必要にアイドル状態になったり、JTA/XAトランザクション・タイムアウトが発生することがあります。
minimumDelayBetweenMessagesの値を設定すると、固定された遅延が発生し、ダウンストリーム・ビジネス・ログのパフォーマンス特性の変更に適応しなくなります。つまり、ダウンストリームのプロセス・フローのパフォーマンスが向上した場合でも、minimumDelayBetweenMessagesは引き続き無条件に適用されます。
たとえば、BPELディスパッチャ・キューの未処理のメッセージ数に関して、ダウンストリームのビジネス・ロジックが増加的にバックログされている場合、このバックログはロジックが受信アダプタ・メッセージの速度に対応できないことを示します。
このプロパティはJCAエンドポイントに適用できるため、エンドポイントに対するすべてのポーリング・スレッドの全体的な遅延が非同期のビジネス・プロセスの実行速度と一致するように値を選択します。
ルールでは、10個のポーリング・スレッドがある場合、有効な遅延= minimumDelayBetweenMessages/ポーリング・スレッド数となります。
JMSアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。
このパラメータは、アダプタ・エンドポイントをアクティブ化するときに作成されるポーラー・スレッドの数を示します。デフォルトは1です。各ポーラー・スレッドは、個別に処理される独自のメッセージを受信するため、スループットが向上します。
EnableStreamingのデフォルトはfalseです。その重要度は使用例に固有ですが、このプロパティをtrueに設定すると、インメモリーDOMとしてペイロードを処理するのではなく、JMS宛先からのペイロードをストリーミングします(アダプタはSDOMのインスタンスを生成します)。SDOM機能は、大きなペイロードを処理する場合に使用する必要があります。
AQアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。
これは、AQアダプタ・エンドポイントをアクティブ化するときに作成されるポーラー・スレッドの数です。デフォルトは1です。各ポーラー・スレッドは、個別に処理される独自のメッセージを受信するため、スループットが向上します。
適切にチューニングされていない場合に必ずしも症状があるわけではありませんが、メッセージの処理が遅くてAQキュー・バックログが増加する場合、処理速度を上げる方法の1つはスレッドの数を増やすことです。
このAQパラメータのデフォルトはfalseで、パラメータは使用例に固有です。この機能は、大きなペイロードの処理中に使用する必要があります。
このプロパティをtrueに設定すると、インメモリーDOMとして処理するのではなく、JMS宛先からのペイロードをストリーミングします(アダプタはSDOMのインスタンスを生成します)。
ファイル/FTPアダプタの最も重要なチューニング・プラクティスおよびパラメータは、次のとおりです。
ファイルおよびFTPアダプタのインバウンド設計は、(インバウンド・ファイル/FTPアダプタ・サービスを使用した)コンポジット・アプリケーションの各デプロイメントによってシングル・ポーラー・スレッドおよびオプションのプロセッサ・スレッド数が作成されるプロデューサ/コンシューマ・モデルに基づいています。
次の手順で、ファイル/FTPアダプタのデフォルトのスレッド動作を示します。
ポーラー・スレッドは、構成されたポーリング頻度に基づいて入力ディレクトリのファイルを定期的にスキャンします。
ポーラーは、インバウンド・ディレクトリで検出した新規ファイルごとに、ファイル名、ファイル・ディレクトリ、変更時間、ファイル・サイズなどの情報を内部システム全体のインメモリー・キューにエンキューします。
プロセッサ・スレッドのグローバル・プール(合計4つ)は、このインメモリー・キューからの処理を待機します。
インメモリー・キュー内のアイテムは、これらのスレッドによってデキューされて処理されます。ファイル・コンテンツがXMLに変換され、SOAインフラストラクチャにパブリッシュされた後、ファイルの削除やアーカイブなどの後処理が実行されます。
これは、ファイル/FTPアダプタの両方のデフォルトのスレッド動作です。ただし、インバウンドJCA構成ファイルのThreadCountまたはSingleThreadModelプロパティのいずれかを構成することによって、この動作を変更できます。
ThreadCountの有限値を設定すると、特定のファイル/FTPアダプタのインバウンド・サービスがパーティション化スレッド・モデルに変更され、そこで各サービスは独自のインメモリー・キューと、一連の専用プロセッサ・スレッドを受信します。
プロセッサ・スレッド自体はSOAワーク・マネージャのもので、メモリーやCPU時間を消費するため、このプロパティは慎重に構成する必要があります。値2から開始して、必要に応じてゆっくり速度を上げることをお薦めします。ただしシステムでは、ThreadCountのこの構成の上限が40に設定されています。
JCAの構成でSingleThreadModelをtrueに設定すると、ポーラーがプロセッサの役割を果たすようになります。つまり、ポーラーが、インバウンド・ディレクトリをスキャンし、同じスレッドのファイルを(次々に)処理します。
このパラメータは、システムを抑制する必要がある場合に特に役立ちます。特定の順序でファイルを処理する必要がある場合(最終変更時間の降順でファイルを処理する場合など)にも、このパラメータを使用できます。
単一の共有インメモリー・キューおよび共有プロセッサ・スレッドが原因で、複数のインバウンド・サービスが実行されているようなボリュームが大きい状況では、パフォーマンスが低下します。
MaxRaiseSizeパラメータは、インバウンド・ファイル/FTPアダプタによって使用され、インバウンド・アダプタのポーラー・スレッドが単一のポーリング・サイクルのインメモリー・キューに生成するファイルの数を決定します。
たとえば、ポーリング頻度を1分、MaxRaiseSizeを10に設定している場合、ポーラー・スレッドは毎分最大10ファイルをインメモリー・キューに生成します。
このパラメータは、ファイル/FTPアダプタがアクティブ/アクティブ・クラスタで実行されるように構成されている場合に役立ちます。この場合、クラスタの同じディレクトリをポーリングするポーラー・スレッドが複数(実際は管理対象サーバーに1つずつ)存在します。このパラメータにより、ファイルはノード間にほぼ均一に分散されるようになり、単一の管理対象サーバーがファイルの処理を独占することがなくなります。
このパラメータが適切にチューニングされていないとバランスが保たれません。たとえば、アクティブ/アクティブ・クラスタの1つの管理対象サーバーがほとんどのメッセージを処理することになります。
MaxRaiseSizeの値が小さいと、各ポーリング・サイクルで処理されるファイルが少なくなり、ポーラー・スレッドのスリープ時間が追加されるため、パフォーマンスが低下する可能性があります。
ファイル/FTPアダプタ内のデバッチの使用例は、単一のインバウンド・ファイルを複数のバッチに分けることが可能で、各バッチが個別に処理されるときに発生します。たとえば、何百万もの請求書が含まれている単一のファイルがある場合、1回の試行でファイル全体を処理することはできません。
デバッチが有効な場合、ファイル/FTPアダプタは、基になるストリームから読み取って最初の1000 (PublishSizeが1000の場合)の請求書をXMLに変換し、SOAにパブリッシュします。この処理は、ファイル全体が処理されるまで続けられます。さらに、アダプタは、クラッシュの回復時に中断した場所からデバッチを再開できるように、反復の間に十分な情報を保存します。
適切なパフォーマンスを実現するには、PublishSizeに十分に大きな値を指定する必要があります。たとえば、ファイルに1,000,000の論理レコードがある場合、PublishSizeを約10,000に設定すると、100回の反復でファイル全体が処理されます。
アダプタからの各パブリッシュは、多数のデータベース・アクティビティ(デハイドレーション・ストアへの格納、後の時点でのリハイドレーションなど)になります。(PublishSizeの値を大きくすることによって)パブリッシュの数を減らすと、パフォーマンスが向上します。
チャンク読取りはデバッチに類似していますが、アウトバウンド・ファイル/FTPアダプタに適用され、さらに重要なことにはBPELでのみサポートされます。
使用例で、チャンク読取りを使用するBPELプロセスは、<while/> BPELコンストラクト内の<invoke>アクティビティを使用して、大量のファイルを1つの論理チャンクで一度に処理します。
各<invoke>の最後に、1つの倫理チャンクがXMLデータとしてBPELに戻されます(メモリーに具現化されます)。
ChunkSizeパラメータは、各<invoke>でBPELに戻される論理レコードの数を定義します。このパラメータを設定する場合、BPELの<while>ループの反復数が大きくなるとメモリーに保持される監査情報量が増加するため、メモリー不足エラーが生じることに注意する必要があります。
ChunkSizeの値を設定する場合、反復数を最小限に抑えると同時に、大きすぎるレコードのチャンクを戻さないようにする必要があります。たとえば、100万のレコードが含まれる大きなファイルがある場合は、大きな値(約1000)から開始する必要があります。
この項では、データベース・アダプタのパフォーマンスおよびチューニングに関連する最も重要なプラクティスおよびパラメータの概要について説明します。
次のような内容が含まれます。
次の情報は、データベース・アダプタでの索引の使用に関連しています。
ポーリングが非常に遅くなる可能性があります。外部キー列が索引化されていない場合、1-Mリレーションシップを使用した削除ポーリング戦略がデッドロックになることがあります。
すべての索引にコストがかかります。フラット表からの純粋な削除の使用および主キーなしの構成(かわりにROWIDを使用)は、索引が必要な場合に有効な代替方法です。未処理の行が数行以上は生じない(DeletePollingStrategyでは再度生じない)速さでアダプタがポーリングできる場合、索引は必要ない可能性があります。
索引を作成するかすべての索引および制約を削除し、ROWIDを使用します(拡張、ポーリングの削除のみ)。
また、索引の使用はデフォルトでfalseになっているパラメータではありません。これはデータベース・アダプタ自体とは別に行うことであり、アダプタが実行するSQLが最適に実行されるように、ポーリングしているリレーショナル・スキーマを変更します。それ自体はチューニング・ノブではありませんが、非常に重要です。
ROWIDオプションによって、迅速な選択が可能になり、索引の維持にかかる従来のコストを回避できます。詳細は、データベース・アダプタの章のROWIDに関する項を参照してください。
次に、MaxTransactionSizeおよびMaxRaiseSizeの考慮事項を示します。
スケーリングするには、トランザクション/フェッチの数(MaxTransactionSize)およびダウンストリーム・インスタンスの数(MaxRaiseSize)を使用してオーバーヘッドを削減します。大量にデータを移動する場合、システムで複数の行を1つのペイロードとして渡すとパフォーマンスを向上できます。
MaxRaiseSize=1は、BPELプロセスが単一のレコードを処理するように設計されている場合など、ビジネス上の制約のためによく使用されます。メッセージを頻繁に拒否する必要がある場合、バッチで複数のレコードを処理すると全体的に遅くなる可能性があります(大量のトランザクションをロールバックし、行を個別に再試行する必要があります)。また、エンド・ツー・エンド・プロセスが大きいMaxTransactionSizeおよび小さいMaxRaiseSizeと同期する場合、多くのダウンストリーム・プロセスが単一のグローバル・トランザクションに参加し、トランザクション・タイムアウトが発生します。
トランザクション・タイムアウトの場合は、(BPELに対する)ポスト非同期を作成したり、MaxTransactionSize/MaxRaiseSizeの比率を削減します。
BPELでは、インスタンスごとのオーバーヘッドが高く、OSBに比べて約10倍です。このうちいくつかは、デハイドレーションとインスタンス・トラッキングに使用されます。ただし、このコストは、各インスタンスが単一XMLの10行を表すか、XMLの1行を表すかのいずれであっても、固定コストのようなものです。そのため、このオーバーヘッドに対処する方法の1つは、複数の行を表すわずかに大きなペイロードをデータベース・アダプタが送受信することです。このようなオーバーヘッドの症状として、純粋なJDBCプログラムに比べて速度が遅くなる場合があります。
このチューニング・パラメータの使用には、非常に慎重になる必要があります。
RowsPerPollingIntervalは、スループットの明示的なキャップで、ダウンストリーム・コンポーネントのバースト・ロードを削減するように設計されており、キャップ・パフォーマンスを強化しすぎないように非常に慎重に使用する必要があります。
ロッキングのスキップの有効化は、重要なパラメータです。
ありませんが、このパラメータはOracle DatabaseおよびSQLServerプラットフォームに対してのみサポートされます。データソースに十分な容量があることを確認してください。接続が十分でない場合は、より多くのスレッドを追加するとより多くの待機スレッドが作成されます。
この項では、NumberOfThreadsの増加の使用について説明します。
ポーリングがスケーリングしません。スケーリングの定義は、パフォーマンスがスレッド/エージェントの数に応じて直線的に増加することです。そのため、スレッドの増加はスケーリングの事前条件になります。他のチューニング・パラメータは、パフォーマンスの向上が直線的になるようにするためのものです(他の同様のスレッドによって速度が低下しないで各スレッドを機能させることでロッキングをスキップします)。
usesSkipLocking=trueのような分散ポーリング戦略を使用しない場合、スレッドの増加が同時に実行されない可能性があります。基となるデータソース接続に少なくとも同じ最大容量があることを確認します。
