[WLS] JMS JDBC Store Performance on Oracle RAC

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/jms_jdbc_store_performance_on

---

JMS周りのパフォーマンステストの多くは、Oracle Real Application Clusters上のJDBCストアを使って行われてきました。この記事の目的は、いくつかの既存のドキュメントを参照しつつ、WebLogic Server 12.1.3の新しい関連機能をご紹介し、さまざまなアプローチをまとめることにあります。

まず、JMSバッキングストアに使っているOracle Databaseの表の最適化に関する提案です。現在のJMSのマニュアルでは”I/Oマルチスレッディング”を有効化する場合にはリバース・インデックスの利用を提案しています。これらは高負荷時にのみ推奨しています。Oracle DatabaseのPartitioningオプションを利用できる場合には、表に対しグローバル・ハッシュ・パーティション・インデックスを利用することができます。これを使うとインデックス競合の削減や、グローバル・キャッシュ・バッファの待機を削減し、アプリケーションの応答時間を劇的に改善することができます。パーティショニングはすべてのケースにおいて有効に働きますが、リバース・インデックスを使った場合には顕著な改善が見られない場合があります。詳しくは以下の記事をご覧ください（この記事にはプールサイズやキャッシュサイズに関して、興味深いコメントも掲載されています）。

Oracle FMW 11g R1 SOA with Oracle Database Real Application Clusters Assessment
Oracle Maximum Availability Architecture White Paper
November 2011
http://www.oracle.com/technetwork/database/availability/maa-fmw-soa-racanalysis-427647.pdf

二つ目におすすめするのは、セキュアファイルを使って性能を改善し、ストレージをより効率的かつ容易に管理する、というものです。これは、一般に、メッセージのサイズが大きい場合や、データベースへのネットワーク接続が遅い場合に、JDBCストアのスループットを改善するために推奨されるものです。セキュアファイルに関する詳細は、以下のホワイトペーパーをご覧ください。

Oracle FMW SOA 11g R1: Using Secure Files
Oracle Maximum Availability Architecture White Paper
September 2012
http://www.oracle.com/technetwork/database/availability/oraclefmw-soa-11gr1-securefiles-1842740.pdf

両者を組み合わせることで、JMSバッキングストアのスキーマは次のようになります。

CREATE TABLE JMS1.JMSWLSTORE (
        ID INT NOT NULL,
        TYPE INT NOT NULL,
        HANDLE INT NOT NULL,
        RECORD BLOB NOT NULL,
        PRIMARY KEY (ID) USING INDEX GLOBAL PARTITION BY HASH (ID) PARTITIONS 8
        TABLESPACE JMSTS
   )
   LOB (RECORD) STORE AS SECUREFILE (TABLESPACE JMSTS ENABLE STORAGE IN ROW); 

パーティションのサイズが一様になるよう、パーティションの個数は2のべき乗である必要があります。パーティションの推奨個数は、予想されるテーブルやインデックスの成長度合いによって変動するため、時間をかけてDBAが分析し、調整する必要があります。関連するパラメータは、以下のOracle Database VLDB and Partitioning Guideをご覧ください。

Oracle® Database VLDBおよびパーティショニング・ガイド
12c リリース1 (12.1)
http://docs.oracle.com/cd/E49329_01/server.121/b71291/toc.htm
Oracle® Database VLDB and Partitioning Guide
12c Release 1 (12.1)
http://docs.oracle.com/database/121/VLDBG/toc.htm

カスタムJMS JDBCストアテーブルを使用する場合には、カスタムDDL機能をご覧ください。

Administering Server Environments for Oracle WebLogic Server
Using the WebLogic Persistent Store
Using Custom File Stores and JDBC Stores
http://docs.oracle.com/middleware/1213/wls/CNFGD/store.htm#i1160628

Real Application Clustersに対してマルチデータソースもしくはActive GridLinkを使っているいずれの場合でもこうした改善の恩恵を受けることができます。
新しいトリックが、WebLogic Server 12.1.3のJMSに性能向上のためののパフォーマンスの飛び道具として追加されました。データベースを使用するすべてのアプリケーションと同様に、アプリケーションからデータベースまでのラウンドトリップすべてにオーバーヘッドがあります。JMS JDBCストアのコードでは、それをサポートするデータベースを用いたバッチ処理を使用しています。設定したバッチサイズ（すなわち、DeletesPerBatchMaximumとInsertsPerBatchMaximum）と、トランザクション内のオペレーションの数に応じて、バッチ実行のための1回以上のラウンドトリップと、1回のコミットのためのラウンドトリップでトランザクションが構成されます。新しい構成オプションであるOraclePiggybackCommitEnabledは、Oracle Thinドライバの場合のみ、バッチ操作にコミットも乗せてしまうというものです。小さなトランザクションでは、1回のラウンドトリップで、バッチを実行し、コミットします。つまり、ラウンドトリップの数の半分にします。
多くの研究が、マルチデータソースとActive GridLinkの両方について、全体的なパフォーマンスをチェックする多くの検証が行われてきました。WebLogic Server 12.1.2での接続アフィニティの強化以後、（ラウンドロビンではなく）フェールオーバーするよう構成されたマルチデータソースのパフォーマンスは、Active GridLinkとほぼ同じです。マルチデータソースのフェイルオーバアルゴリズムでは、接続アフィニティを有しているため、失敗するまで1つのインスタンスですべての接続を保持します。WebLogic Server 12.1.1以前では、Active GridLinkは単一インスタンスへの接続アフィニティを持たないため、フェールオーバを有効にしたマルチデータソースは、Active GridLinkよりもパフォーマンスに優れていました。管理性やフェールオーバを含む多くの領域で、より優れたRACサポートを提供しているため、マルチデータソースでActive GridLinkを使うことをおすすめします。詳細は以下のドキュメントをご覧ください。

Administering JDBC Data Sources for Oracle WebLogic Server
Using Active GridLink Data Sources
Comparing AGL and Multi Data Sources
http://docs.oracle.com/middleware/1212/wls/JDBCA/gridlink_datasources.htm#BABHGDJH

ただし、Active GridLinkの利用にはWebLogic SuiteもしくはExalogic Elastic Cloud Software（EECS）が必要です。最後に、パフォーマンスを出すための鍵は、（想像されている通り）ワークスレッドの個数だけではなく、同時に利用するプロデューサやコンシューマの個数です。10個を下回るプロデューサやコンシューマの場合、前述の通りハッシュ・パーティションを使ったインデックスやLOB用のセキュアファイルを伴う通常の複数RACインスタンス上のサービスを使ってください。（9個以上のプロデューサやコンシューマがいるような）より高い同時実行性を求める場合、シングルトン・データベース・サービスを使うとより効率がよいでしょう。優先インスタンスや高可用性のためのフェールオーバ・インスタンスを使って構成しておくべきです。
JMS JDBCストア用途で利用する場合、WebLogic Serverデータソースをチューニングしておくと、JMSのスループットおよび当該JMSを利用するアプリケーションのパフォーマンスを劇的に改善することができます。パフォーマンス調査にあたっては、ご自身のアプリケーションやデータを使って実施する必要があります。