FMWストレッチ・クラスタの追加最適化の構成
このトポロジではすべて必須ではありませんが、パフォーマンスが向上し、特定の機能およびシナリオの動作が向上します。
Oracle WebLogic Server (WLS)でのタイムアウトの構成
データベース内のトランザクション、トランザクション・ブランチ、Enterprise JavaBean (EJB)メソッドの起動、Webサービスなどのタイムアウト制限が指定されています。Oracle Fusion Middlewareのストレッチされたクラスタ・デプロイメントは、タイムアウト設定に特に影響します。これは、複数の操作で異なる場所のデータベースにアクセスする必要があるためです。次のようなタイム・アウトを構成します。
- システムでレイテンシが発生します。
待機時間が原因で、これらのタイプのシステムのタイムアウトを増やす必要がある場合があります。ストレッチされたクラスタ・モデルでは、ドメイン設定は両方のサイトで共有されるため、最悪のシナリオを考慮したタイムアウトを使用する必要があります。
- これらは、様々なレイヤーにわたる呼出しのチェーンで適切に期限切れになります。
適切な取り込み層が正しく動作するように、システムの異なる層でタイムアウトを構成する必要があります。たとえば、データベース・タイムアウトがグローバルWLSタイムアウトより小さい値に設定されている場合、他のブランチでの作業が完了する前に、トランザクションIDがデータベースから「削除」されることがあります。
様々なレイヤーの主なタイムアウト・パラメータは次のとおりです。
- グローバル・トランザクションのタイムアウト
Oracle WebLogic Serverグローバル・トランザクション・タイムアウトによって、分散トランザクション(グローバル・トランザクション)がOracle WebLogic Serverによって自動的にロールバックされるまでにアクティブのままにできる最大期間(秒単位)が決まります。「ツリーの編集」の「サービス」セクションで「JTA (Java Transaction API)」を選択し、「タイムアウト秒」を指定して、WebLogicリモート・コンソールでグローバル・トランザクション・タイムアウトを構成します。
- XAトランザクションのタイムアウト
XAデータ・ソースのXAトランザクション・タイムアウトは、Oracle WebLogic Serverでデータ・ソースのトランザクション・ブランチ・タイムアウトを設定するために使用されます。デフォルトでは、この値は0 (ゼロ)に設定されているため、WebLogicグローバル・トランザクション・タイムアウトが使用されます。ただし、XAリソースでデフォルト・タイムアウト値を超える長時間実行トランザクションがある場合には、この値を設定できます。この値は、「トランザクション」タブのXAデータ・ソースごとに構成されます。
- 分散ロック・タイムアウト
データベースの分散ロック・タイムアウトでは、分散トランザクションによるロック済リソースの待機時間(秒)を指定します。パラメータ(
distributed_lock_timeout)は、適切なSQL ALTER文を使用して変更できます。
サイト間のネットワーク遅延を考慮して、最も遅いトランザクションに十分な長さのデータベースの分散ロック・タイムアウトを設定します。その後、次のルールを使用して、XAデータ・ソースおよびグローバル・トランザクション・タイムアウトを低い値に設定します。
distributed_lock_timeout >= XA DS Timeout >= Global Transaction Timeoutアプリケーションでは、追加のタイムアウト・パラメータを使用できます。たとえば、Oracle SOAおよびBPELには、次の追加のタイムアウト・パラメータがあります。
- syncMaxWaitTime
syncMaxWaitTimeは、同期クライアントがレスポンスを待機する最大時間です。この設定は、リクエストおよびレスポンス操作がタイムアウトするまでにかかる時間を定義します。BPELプロセスがこの時間内に応答を取得しない場合、アクティビティは失敗します。Oracle Enterprise Manager Fusion Middleware Controlでこの値を変更するには:
- 「SOA-infra」を右クリックして「SOA管理」を選択します。
- 「BPELプロパティ」を選択します。
- 詳細BPEL構成プロパティを選択します。
- syncMaxWaitTime値を更新します(秒)。
- EJBのタイムアウト
BPEL EJBメソッドが関係する場合、トランザクション・タイムアウトを秒単位で指定します(すべてのBPEL EJBのデフォルトは300です)。次のようにタイムアウトを変更します。
- WebLogicリモート・コンソールのモニタリング・ツリーで、「デプロイメント」、「アプリケーション管理」の順に選択します。
- soa_infraアプリケーションを展開し、「構成」および「サブデプロイメント」を展開します。
- モジュールを拡張して、特定のBPEL EJBを選択します。
Global Transaction Timeout > BPEL EJB's transaction timeout > syncMaxWaitTime - Webサービス・クライアントのタイムアウト
Webサービス・クライアントは、最悪のレイテンシで十分に許容できるタイムアウトで構成する必要があります。たとえば、コールがサイト1から3秒かかるが、サイト2から10秒かかる場合、タイムアウトは、低速なサイトを処理するために少なくとも10秒に設定する必要があります。
- BPELプロセスのタイムアウト
BPELプロセスで特定のリクエスト・リプライ(同期)および受信のみ(非同期)のタイムアウトを使用している場合は、最悪のシナリオ(コールがデータベース・レイテンシが最も高いサイトに移動する場合)に基づいて定義する必要があります。これらのタイムアウト設定はBPELプロセス内で定義され、サイトごとに異なる設定を行うことはできません。BPELプロセスでのイベントおよびタイムアウトの構成の詳細は、『Oracle Fusion Middleware Oracle SOA Suite開発者ガイド』を参照してください。「まとめの問題」の項を参照してください。
セッション・レプリケーションの構成
一部のアプリケーション(Webアプリケーション、Oracle SOAコンポーザ、BPMコンポーザ、BPMワークスペースなどのコンソール)では、HTTPセッション・オブジェクトが集中的に使用されます。
Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・デプロイメントの利点の1つは、サイト間のシームレスなフェイルオーバーを実現する機能です。ただし、リージョン間のセッション・レプリケーションでは、システムのパフォーマンスが低下する可能性があります。Oracleでは、2つのサイト間のレプリケーションを最小限に抑えるために、2つの異なるレプリケーション・グループ(リージョンごとに1つ)を定義することをお薦めします。
セッション・レプリケーション・グループを構成するには、次のようにします。
- WebLogic Remote Console編集ツリーで、「環境」、「サーバー」の順に選択します。
- 「サーバー名」を選択し、「クラスタ」タブを選択します。
- リージョン1のサーバーごとに、同じレプリケーション・グループ名(Region1RepGroupなど)を入力します。
- リージョン2のサーバーに対して、リージョン1で使用されるサーバーとは別の共通名(Region2RepGroupなど)を使用してステップを繰り返します。
レプリケーション・グループを使用することは、同一サイト内のサーバーのみに状態をレプリケートする最善の方法ですが、決定的な方法ではありません。一方のサイトで1つのサーバーが使用でき、その他のサーバーがもう1つのサイトで使用できる場合、リージョン間でレプリケーションが発生し、サーバーが同じサイトでオンラインになってもそのセッションに対して続行します。
JMSのインプレース再起動の構成
永続ストアは、Oracle WebLogic Server (WLS)サーバーの適切な機能にとって重要です。インプレース再起動では、永続ストアでエラーが発生した場合、JMSサービスは、別のサーバーへの移行を試行する前に、同じサーバーでの再起動を試行します。この方法は、JMSサービス全体を別のサーバーに移行するよりも高速であり、多くの場合、問題を迅速に解決できます。
JMS永続ストアのインプレース再起動を構成するには、関連するJMSサーバーおよび永続ストアを移行可能なターゲットにターゲット指定する必要があります。この移行可能ターゲットでは、デフォルトで有効になっていない「失敗時に再起動」を使用する必要があります。このプロパティを構成するには、次のステップに従います。
- WebLogicリモート・コンソールへの接続
- ツリーの編集で、「環境」、「移行可能なターゲット」の順に選択します。
- 移行可能なターゲットを選択し、「失敗時に再起動」を有効にします。
- 「保存」を選択し、変更をコミットします。
Oracle FMW SOA Suite JMSアダプタの構成
Oracleでは、クラスタ構文(たとえば: cluster:t3s://cluster_name)を使用して構成を簡略化することをお薦めします。このアプローチにより、アダプタがクラスタ内のアクティブなサーバーの現在のリストを動的に取得できるようになり、JNDIコンテキストを効率的に取得できるようになり、構成が簡略化されます。
システムがJMSアダプタを集中的かつ大きなペイロードで使用する場合は、各リージョン内のローカル・サーバーのみを含めるようにJNDI URLを構成することをお薦めします。これは、リージョン1の構成にリージョン1のサーバーを指定し、リージョン2の構成にリージョン2のサーバーを指定することを意味します。この設定により、サイト・コンテキスト・アフィニティが保証され、パフォーマンスが最適化され、レイテンシが削減されます。
Oracle FMW SOA Suiteファイル・アダプタの構成
このメカニズムにより、同じファイルが一度に1つのサーバーによってのみ処理され、2つのアダプタ・インスタンスが同時に同じファイルに書き込まれないことが保証されます。
Oracle Fusion Middleware (FMW)ストレッチ・クラスタ・トポロジでは、各サイトは独立して動作し、専用の共有記憶域を使用してファイルを処理します。ただし、デフォルトでは、両方のサイトで、ファイル・ロックおよび相互排他ロックのメカニズムに同じデータ・ソース、スキーマおよび表が使用されます。
アウトバウンド操作では、共有データベース表の使用が適しています。これは、同時書込み操作でファイルが上書きされないように、一意の順序が相互排他ロックとして使用されるためです。
ただし、インバウンド操作では処理中シナリオが発生する可能性があります。いずれかのサイトのファイル・アダプタ・インスタンスは、ファイルをブロック済としてマークできます。両方のサイトに同じファイル名が存在する場合、このメカニズムは両方の場所でその処理をブロックできますが、ファイルはどちらか一方のみで消費されます。このような状況を回避するために、複数の代替方法があります。
- サイト固有のファイル命名規則を実装します。サイトに基づいて一意の識別子をファイル名に使用すると、名前の衝突や後続のブロックの可能性が低くなります。
- ファイル・アダプタのロック表および相互排他表に対して、各リージョンに別々のスキーマを構成して、ファイル・ロックおよび相互排他メカニズムが独立して動作するようにし、クロスサイト・ブロックを防止します。
- ファイル・アダプタのロック表とmutex表に別のデータベースを使用して、ファイル処理メタデータが個別に管理されるようにします。
異なるデータベースまたは各リージョン内の個別のスキーマを使用するようにファイル・アダプタを構成するには、適切なスキーマ所有者および表を作成し、新しいデータ・ソースを確立する必要があります。リージョン1のサーバーは引き続き元のデータ・ソースを使用し、リージョン2のデプロイメント・プランのみが新しいデータ・ソースを使用するように変更されます。
リージョン1のサーバーは元のデータ・ソースを使用し、リージョン2のサーバーは新しいデータ・ソースを使用します。
Oracle Fusion Middleware Oracle SOA SuiteインメモリーSOAの構成
これにより、読取りおよび書込み操作がキャッシュから実行されるため、これらのビジネス・プロセスのパフォーマンスとスケーラビリティが向上します。
BPEL状態情報は、Oracle Coherenceキャッシュに格納され、キャッシュからプルされます。フォルトが発生した場合のみ、またはwrite-behindスレッドを使用して一定の間隔で、プロセスの状態はデータベースに書き込まれます。
インメモリーSOAは、Oracle Fusion Middlewareストレッチ・クラスタ・トポロジではサポートされません。この場合、遅延の影響を受けやすいため、Coherenceキャッシュの使用は最小限に抑える必要があります。
WebLogicデータベース・リースのチューニングの構成
データベース・リースは、自動サービス移行をサポートするために使用されるコア・メカニズムであり、特にJMSサーバーやJTAトランザクション・リカバリ・サービスなどのクラスタ化されたシングルトン・サービスに使用されます。クラスタ内の複数のサーバー間でこれらのシングルトン・サービスの所有権を管理および調整するために使用されます。このメカニズムでは、データベースを中心として使用して、クラスタ内のどのサーバーが任意の時点で所有しているか、または特定のシングルトン・サービスを管理しているかを確実に追跡および制御します。これを行うには、データベース内にリースレコードを格納します。このレコードは、所有サーバーによって定期的に更新(更新)されます。『Oracle WebLogic Serverクラスタの管理』の移行可能なサービスのためのリースに関する項を参照してください。
このガイドで前述したGridLinkデータ・ソースの構成により、データベース・フェイルオーバーまたはスイッチオーバーの実行時の自動再接続が保証されます。ただし、データベース・リースまたはJDBC永続ストアを使用して構成されたすべてのサーバーは、データベースの停止、スイッチオーバーまたはフェイルオーバー中に停止できます。クリティカルなサブシステム(JTAサービスなど)に障害が発生すると、サーバーはFAILED状態に設定され、ノード・マネージャによって自動的に再起動されます。
FAILED状態への所要時間は可変であり、関連するチェックがいつトリガーされるかによって異なり、様々な理由で発生する可能性があります。
- サーバーが合計再試行回数後にリース表を更新できない場合。
- サーバーが様々な再試行およびインプレース再起動後にJTA JDBC永続ストアにアクセスできない場合。
データベースのスイッチオーバーには数分かかる場合があります。JTA JDBC永続ストアへのアクセスが失われることによるWLSサーバーの自動再起動は、約8分から9分ほどかかるため、データベースの一般的なスイッチオーバーまたはフェイルオーバー時にはトリガーされません。ただし、デフォルトのリース構成では、リースが2分未満で失われるため、サーバーはFAILED状態に遷移できます。したがって、Oracle WebLogic Serverの再起動は、Oracle Data Guardのスイッチオーバーまたはフェイルオーバー時に自動的にトリガーできます(そのWebLogicサーバーがデータベース・リースを使用している場合)。
データベース・リースを使用するサーバーのデータベース停止に対する回復性を向上させるには、2つのパラメータがあります。これらのパラメータは、database-leasing-basis-connection-retry-count (デフォルトでは1回の再試行)およびdatabase-leasing-basis-connection-retry-delay (デフォルトでは1秒)です。これらのパラメータを増やすと、リースの欠落エラーが発生するまでの時間が長くなります。これにより、WebLogicサーバーは、自動的に再起動することなく、より長いデータベース停止を許容できます。データベースを再度使用可能になったら、データベースに再接続するだけです。データベースが停止している間、接続試行は失敗しますが、WebLogicサーバーは再起動されません。
したがって、ストレッチされたクラスタでは、「データベース・リース接続の再試行回数」および「タイムアウト」の値を大きくして、WebLogicサーバーのデータベース停止に対する耐障害性を高めることをお薦めします。これらのプロパティを変更するには、WLSTコマンドを使用します。たとえば:
$ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('weblogic','password','t3s://ADMINVHN:9002')
edit()
startEdit()
cd('/Clusters/' + 'My_Cluster')
cmo.setDatabaseLeasingBasisConnectionRetryCount(10)
cmo.setDatabaseLeasingBasisConnectionRetryDelay(10000L)
save()
activate()
disconnect()
exit()ヒント :
サーバーがFAILED状態になると、ノード・マネージャはデフォルトでサーバーの再起動を2回試行します。サーバーを正しく起動できない場合は、FAILED_NOT_RESTARTABLEとしてマークされます。サーバーの「Health」タブで再起動の数をチューニングできます。「再起動間隔」で指定した間隔内で、ノード・マネージャがこのサーバーを再起動できる回数を定義するには、パラメータ「再起動間隔」を使用します。Coherenceを構成する
たとえば、Oracle SOA Suiteでは、Oracle Coherenceを使用して、クラスタ間でコンポジット・デプロイメントおよびメタデータ(MDS)更新を伝播します。
Oracle Coherenceでは、クラスタ・メンバーの検出とメッセージングのためのマルチキャスト通信とユニキャスト通信の両方がサポートされています。ユニキャストは、複数のデータ・センターやクラウド・リージョン間など、マルチキャストが使用できない環境やサポートされていない環境で特に適しています。既知のアドレス(WKA)機能を使用すると、クラスタ・メンバーはマルチキャストに依存せずにクラスタを検出および結合できます。WKAが構成されると、すべてのマルチキャスト通信が無効になります。デフォルトでは、Oracle Fusion Middleware製品はCoherence用に事前定義されたWKAリストを使用してユニキャストを利用します。
Oracle Coherenceは、クラスタ形成時およびクラスタ・メンバーからのハートビートへの応答時の遅延の影響を受けます。ただし、最新バージョンでは、allowable varianceなどの機能による通信遅延に対する許容性が向上しています。allowable varianceは、Coherenceクラスタ内のネットワーク通信で許容されるタイミングのバリエーションを定義します。この構成可能なパラメータ(maximum-time-variance)は、デフォルトで16ミリ秒に設定され、往復時間(RTT)UDP通信の最大許容レイテンシを設定します。Coherenceは、観測されたネットワーク・レイテンシまたは不整合に応じてこの値を動的に調整し、予測されるタイミングの偏差の増大に対応することでクラスタの安定性とパフォーマンスを維持します。メッセージIncreasing allowable variance to XXは、このような調整を示します。Oracle Coherenceでのアプリケーションの開発の「オペレーション構成の要素」を参照してください。
Oracle Coherenceのこの改善により、FMWストレッチ・クラスタ・トポロジ(RTTが10ミリ秒未満)の推奨制限内に待機時間が残っている場合、クラスタの形成に関するエラーは報告されません。ただし、クラスタ・ハートビートの遅延が長くなると、デプロイメントの競合や停止に対する不適切な反応時間が発生する可能性があります。
Coherenceクラスタの形成または操作でエラーが発生した場合は、次のCoherenceネットワーキング・タイムアウト・パラメータを調整できます。
<multicast-listener><join-timeout-milliseconds>. もともとマルチキャスト構成用に設計されていましたが、ユニキャストでの結合タイムアウトの影響も同様です。これは、初期ノードがクラスタを形成するのにかかる時間を決定し、その後、各ノードが独自のノード(WKAリスト上にある場合)を形成しようとする前にクラスタの検索に費やす時間を決定します。デフォルト値は3000です。信頼性の低いネットワークでは、新しいクラスタを開始する前にクラスタの検索に長い時間を費やすために、この値を増やす必要がある場合があります。<packet-publisher><packet-delivery><resend-milliseconds>. パケットの再送信間隔は、送信に対応するACKパケットをパケット・パブリッシャが待機する最小時間(ミリ秒)を指定します。この時間が経過するとパケットが再送信されます。これはRTTのいくつかの倍数である必要があります。10xで問題ありません。デフォルト値は200です。<packet-publisher><packet-delivery><timeout-milliseconds>. 確認が要求されるパケットの場合、最大時間をミリ秒単位で指定します。この時間を超過すると、パケットが再送信されます。このタイムアウトが経過した後、Coherenceでは受信側が終了していると見なすかどうかが決定されます。デフォルト値の5分で十分ですが、クラスタへの参加時のタイムアウトを回避するために値を増やすことができます。<packet-publisher><packet-delivery><heartbeat-milliseconds>このパラメータは、tcp-ring停止検出のハートビート間隔です。デフォルトのハートビート値は1秒です。値を増やすとネットワークトラフィックを緩和できますが、これにより障害が発生したメンバーの検出も延長されます。<tcp-ring-listener><ip-timeout>および<ip-attempts>。これらは、クラスタ・メンバーをホストしているコンピュータは到達不可能になっていないと判断するまでの試行回数です。Ip-timeoutは、RTTの10x以上の領域(5s以上)である必要があります。<cluster-config><tcp-ring-listener><enabled>. tcp-ring停止検出を無効にしてネットワークトラフィックを緩和することもできますが、障害が発生したメンバーの検出に時間がかかります。死亡検出を無効にするには、falseに設定します。無効にすると、クラスタ・メンバーはパケット・パブリッシャの再送信タイムアウト間隔を使用して、別のメンバーがUDPパケットへの応答を停止していることを判断します(デフォルトでは5分に設定されています)。
デフォルトの構成設定を変更するには、Coherenceオーバーライド・ファイルを使用します。custom-coherence-override-<name>.xmlという名前のファイルを作成し、クラスタ内のすべてのサーバーから一貫性があり、アクセス可能であることを確認します。このファイルは、javaプロパティtangosol.coherence.overrideで指定します。これは、setUserOverrides.shファイルのEXTRA_JAVA_PROPERTIES javaプロパティで設定できます。たとえば:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dtangosol.coherence.override=/u01/oracle/config/coherence_custom/custom-coherence-override.xml"パラメータをチューニングするCoherenceオーバーライド・ファイルの例:
<?xml version='1.0'?>
<!--
This is a custom operational configuration override
-->
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd"
>
<cluster-config>
<multicast-listener>
<join-timeout-milliseconds>5000</join-timeout-milliseconds>
</multicast-listener>
<tcp-ring-listener>
<ip-timeout>20s</ip-timeout>
<ip-attempts>3</ip-attempts>
</tcp-ring-listener>
<packet-publisher>
<packet-delivery>
<resend-milliseconds>200</resend-milliseconds>
<timeout-milliseconds>650000</timeout-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>
tcp-ring間隔をチューニングするCoherenceオーバーライド・ファイルの例:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<packet-publisher>
<packet-delivery>
<heartbeat-milliseconds>5000</heartbeat-milliseconds>
</packet-delivery>
</packet-publisher>
</cluster-config>
</coherence>tcp-ring停止検出を無効にするCoherenceオーバーライド・ファイルの例:
<?xml version='1.0'?>
<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-config coherence-operational-config.xsd">
<cluster-config>
<tcp-ring-listener>
<enabled>false</enabled>
</tcp-ring-listener>
</cluster-config>
</coherence>
ネット・サービスのパフォーマンスの構成
一部のオペレーティング・システムのデフォルト構成は最適化されない可能性があり、一部のパラメータを調整してデータ転送をより効率的にすることが非常に重要になります。これらの調整は、JDBCクライアントとサーバーの間にレイテンシが大きい場合に特に重要になります。データベース・アクセスのレイテンシが最も高いサーバーは、ネットワーク・バッファおよびOracle Net Services設定の構成をガイドしてパフォーマンスを最適化する必要があります。
最適な構成を決定する際の主要な指標の1つは、帯域幅遅延製品(BDP)です。これは、任意の時点でネットワーク内で転送可能なデータの最大量を表します。これは、ネットワーク・リンクの容量(帯域幅)にラウンドトリップ遅延時間(レイテンシ)を乗算して計算されます。
BDP = Bandwidth × Round-Trip Time (RTT)- RTT: OCIでは、OCIコンソールのリージョン間レイテンシ・ページから、リージョン間の平均RTTを取得できます。または、数分間ホスト間でピン留めなどのコマンドを使用してラウンドトリップ時間(RTT)を決定し、返されたレスポンス時間を使用することもできます。
- 帯域幅: OCIリージョン間には帯域幅が保証されておらず、OCIは特定のOCI帯域幅測定ツールを提供していません。正確な帯域幅測定のために、iPerfなどのツールを使用してテストを実行できます。フランクフルトとアムステルダムの間でテストされた帯域幅は約2~2.5Gbpsです。
TCPソケット・バッファ設定は、ネットワーク経由で一度に送信されるパケット数を制御します。最適なスループットを実現するには、ソケット・バッファ・サイズを少なくともBDPに設定することをお薦めします。多くの場合、バッファ・サイズをBDPの2倍に設定すると、特に高レイテンシ・ネットワークのパフォーマンスがさらに向上します。ただし、バッファが大きすぎると、メモリー使用量が増加する可能性があります。したがって、BDPの範囲内のバッファ・サイズをBDPの3倍に設定することをお薦めします。
BDP ≤ Socket Buffer Size ≤ 3 × BDPデータベースでのIOバッファ・サイズの構成
SEND_BUF_SIZEパラメータを設定すれば十分です。
データベース・サーバーが大きなリクエストを受信している場合は、RECV_BUF_SIZEパラメータも設定します。SSHなどの通常のTCPセッションで追加のメモリーを使用しないように、データベース内のOracle Net Servicesレベルでオペレーティング・システム・レベルではなくチューニングすることをお薦めします。
データベース・サーバーのこれらのパラメータを構成するには、listener.oraファイルまたはsqlnet.oraファイルでバッファ領域サイズを設定します。
-
listener.oraファイルには、特定のプロトコル・アドレスまたは記述子のバッファ・スペース・パラメータを指定します。次に、Oracle Cloud Infrastructure (OCI)のベース・データベース・システムでの一般的なOracle RACリスナー構成の設定の例を示します:LISTENER_SCAN2=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN2)))) LISTENER_SCAN1=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN1)))) LISTENER_SCAN3=(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER_SCAN3)))) (…) LISTENER=(DESCRIPTION=(SDU=65535)(SEND_BUF_SIZE=10485760)(RECV_BUF_SIZE=10485760)(ADDRESS_LIST=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))) -
パラメータが
sqlnet.oraに設定されている場合は、すべてのリスナーにグローバルに適用されます。sqlnet.oraファイルでの設定の例を次に示します。RECV_BUF_SIZE=10485760 SEND_BUF_SIZE=10485760
中間層ノードでのIOバッファ・サイズの構成
Linuxオペレーティング・システムは、受信バッファと送信バッファの両方に自動チューニングを使用します。
受信バッファの場合、自動チューニングは/proc/sys/net/ipv4/tcp_moderate_rcvbufパラメータによって決定されます。パラメータの値が1の場合、自動チューニングが有効になります。自動チューニングでは、受信側のバッファ・サイズ(およびTCPウィンドウ・サイズ)が接続ごとに動的に更新され、最大バッファ・サイズは4MBになります。
送信者バッファでは、自動チューニングもデフォルトで有効になっています。受信バッファの自動チューニングはtcp_moderate_rcvbufパラメータで制御できますが、送信バッファの自動チューニングには直接トグルがありません。固定バッファ・サイズを設定すると、送信バッファの自動チューニングが無効になります。
これらの自動チューニング・プロセスは、データを送受信するためのメモリー割当てを管理するいくつかのカーネル・パラメータによって管理されます。
- 接続バッファ・サイズごと
各TCP接続のメモリー割当ては、次の2つのパラメータで定義されます。
/proc/sys/net/ipv4/tcp_rmem: TCP受信バッファ用に予約されているメモリーを指定します。/proc/sys/net/ipv4/tcp_wmem: TCP送信バッファ用に予約されているメモリーを指定します。
どちらのパラメータも、次の3つの値を受け入れます。
- 最小バッファ・サイズ: TCPソケットに割り当てられる最小バッファ・サイズ。
- デフォルト・バッファ・サイズ: 作成時にTCPソケットに割り当てられる初期バッファ・サイズ。
- 最大バッファ・サイズ: TCPソケットに自動的に割り当てることができる最大バッファ・サイズ。
これらの設定により、自動チューニング・メカニズムの境界が確立され、特にメモリー負荷時のメモリー使用量のバランスがとれます。
- アプリケーションごとのバッファ・サイズ
アプリケーションは特定のバッファ・サイズをリクエストできますが、これらのリクエストには、次のパラメータで定義された制限が適用されます。
/proc/sys/net/core/rmem_maxは、アプリケーションがリクエストできる受信バッファ・サイズの上限を設定する最大受信ウィンドウです。/proc/sys/net/core/wmem_maxは、アプリケーションがリクエストできる送信バッファ・サイズの上限を設定する最大送信ウィンドウです。
IOバッファ・サイズを調整するには:
TCP自動チューニングは、ネットワークの帯域幅遅延製品用にサイズ設定された境界で有効なままであるため、システムのメモリー使用量をオーバーサイズすることなくスループットを向上させます。
セッション・データ・ユニット・サイズの構成
Oracle Net Servicesは、これらのユニットがいっぱいになるまで待機してから、ネットワーク経由で送信します。これらの各バッファは、セッション・データ・ユニット(SDU)です。Oracle Net Servicesに提供されるデータ量にSDUのサイズを調整すると、Oracle Fusion Middlewareストレッチ・クラスタのパフォーマンス、ネットワーク使用率およびメモリー消費が向上し、5ミリ秒RTTよりもレイテンシが高くなります。
SDUサイズは、512バイトから2MBまで設定できます。Oracle Database 23aiでは、デフォルトのSDUサイズは64KB (65,536バイト)です。以前のデータベース・リリースでは、デフォルトのSDUサイズが8KBに設定されていました。
実際に使用されるSDUサイズは接続時にクライアントとサーバー間でネゴシエーションされ、2つの値の小さい方になります。デフォルト以外のSDUサイズを構成する場合、クライアントとサーバーの両方のコンピュータでSDUを構成します。Oracleでは、SDUを可能な最大値(64k)に設定することをお薦めします。
クライアントとサーバーは、接続時にSDUをネゴシエートします。双方を構成することで、意図したSDUが確実に使用されます。