Java 仮想マシンのチューニング

WebSphere® eXtreme Scale の最善のパフォーマンスを得るために、Java 仮想マシン (JVM) チューニングの特定の局面をいくつか考慮してください。ほとんどの場合、特殊な JVM 設定はほとんどまたはまったく必要ありません。データ・グリッドに保管されるオブジェクトが多数ある場合は、ヒープ・サイズを適切なレベルに調整して、メモリー不足の状態で実行されるのを避けます。

eXtremeMemory を構成することにより、オブジェクトを Java ヒープでなく ネイティブ・メモリーに保管できます。eXtremeMemory を構成すると、新しいトランスポート・メカニズムである eXtremeIO が 使用可能になります。オブジェクトを Java ヒープから移動することで、ガーベッジ・コレクションに伴う 一時停止を回避でき、より安定したパフォーマンスを得られるうえ、応答時間も予測可能になります。詳しくは、IBM eXtremeMemory および IBM eXtremeIO の構成を参照してください。

試験済みプラットフォーム

パフォーマンス・テストは、まず AIX® (32 way)、Linux (4 way)、および Windows (8 way) のコンピューターで実行されました。 ハイエンド AIX コンピューターを使用すると、大量のマルチスレッド・シナリオをテストして、競合ポイントを特定して修正できます。

ガーベッジ・コレクション

WebSphere eXtreme Scale は、要求や応答など各トランザクション、およびログ・シーケンスに関連した一時オブジェクトを作成します。これらのオブジェクトはガーベッジ・コレクションの効率に影響するため、ガーベッジ・コレクションのチューニングは重要です。

最新の JVM はすべてパラレル・ガーベッジ・コレクション・アルゴリズムを使用しています。つまり、より多くのコアを使用することでガーベッジ・コレクションの中断を減らせるようになっています。 8 個のコアを使用している物理サーバーは、4 個のコアを使用している物理サーバーよりガーベッジ・コレクションの速度が上がります。

アプリケーションにより区画ごとに大量のデータを管理する必要がある場合は、ガーベッジ・コレクションが要因になっている可能性があります。世代のコレクターが使用されている場合は、大きなヒープ (20 GB 以上) でも、ほとんどが読み取りのシナリオは正常に機能します。ただし、保有ヒープがいっぱいになった後は、コンピューターで使用可能なヒープ・サイズおよびプロセッサー数に比例して一時停止が発生します。この一時停止は、大きいヒープを持つ小さいコンピューターで大きくなる可能性があります。

Java ガーベッジ・コレクション用の IBM 仮想マシン

IBM® の Java 仮想マシンの場合、更新率が高いシナリオ (トランザクションの 100% がエントリーを変更する) には optavgpause コレクターを使用してください。データがほとんど更新されない (10% 以下の頻度) ようなシナリオでは、optavgpause コレクターより gencon コレクターの方がより適切に機能します。両方のコレクターを使用して実験を行い、シナリオで最も適切に機能するコレクターを確認します。詳細ガーベッジ・コレクションをオンにして実行し、ガーベッジの収集に費やされている時間の割合を確認します。チューニングで問題が修正されるまでガーベッジ・コレクションで時間の 80% が費やされたシナリオが発生しました。

ガーベッジ・コレクションのメカニズムを変更するには、-Xgcpolicy パラメーターを使用します。-Xgcpolicy パラメーターの値は、使用するガーベッジ・コレクターに応じて、-Xgcpolicy:gencon または -Xgcpolicy:optavgpause に設定できます。

その他のガーベッジ・コレクション・オプション

重要: Oracle JVM を使用している場合は、デフォルトのガーベッジ・コレクションの調整とポリシーのチューニングが必要となることがあります。

WebSphere eXtreme Scale は、WebSphere Real Time Java をサポートします。WebSphere Real Time Java を一緒に使用することによって、WebSphere eXtreme Scale のトランザクション処理応答はより一貫性のある、予測可能なものになります。結果として、ガーベッジ・コレクションおよびスレッド・スケジューリングの影響は大幅に小さくなります。応答時間の標準偏差が 標準 Java の 10% よりも小さくなる程度まで、影響は少なくなります。

JVM パフォーマンス

WebSphere eXtreme Scale は、Java Platform, Standard Edition の各種バージョンで稼働します。WebSphere eXtreme ScaleJava SE バージョン 5、Java SE バージョン 6、および Java SE バージョン 7 をサポートします。開発者の生産性およびパフォーマンスを向上させるためには、Java SE バージョン 5、バージョン 6、または Java SE バージョン 7 を使用して、アノテーションおよび改良されたガーベッジ・コレクションを活用してください。 WebSphere eXtreme Scale は、32 ビットまたは 64 ビット版の Java 仮想マシンで動作します。

WebSphere eXtreme Scale が テストされたのは、使用可能な仮想マシンの一部ですが、サポートのリスト は排他的なものではありません。Edition 5 以降のどのベンダー JVM 上でも WebSphere eXtreme Scale を実行できます。ただし、ベンダー JVM で問題が発生した場合は、その JVM ベンダーにサポートを依頼する必要があります。可能であれば、 WebSphere Application Server がサポートするどのプラットフォーム 上でも、WebSphere ランタイムの JVM を使用 してください。

一般に、最良のパフォーマンスを得るためには Java Platform, Standard Edition の最新バージョンを使用してください。

ヒープ・サイズ

4 コア当たり 1 JVM で 1 から 2 GB のヒープをお勧めします。最適なヒープ・サイズ 値は、次の要因に基づきます。
  • ヒープ内のライブ・オブジェクトの数。
  • ヒープ内のライブ・オブジェクトの複雑さ。
  • JVM 用に使用可能なコアの数。

例えば、10 K バイトの配列を 保管するアプリケーションは、POJO の複雑なグラフを使用するアプリケーションよりもずっと大きなヒープを実行できます。

スレッド数

スレッド数はいくつかの要因に依存します。単一の断片が管理できるスレッド数には制限があります。断片とは区画のインスタンスであり、プライマリーまたはレプリカとすることができます。JVM ごとの断片数が多いほど、それぞれ追加断片を持つスレッドが増えるので、データへの並行パスが多くなります。各断片は可能な限り並行ですが、それでも並行性について制限はあります。

オブジェクト・リクエスト・ブローカー (ORB) 要件

IBM SDK には、WebSphere Application Server および WebSphere eXtreme Scale を使用してテスト済みの IBM ORB 実装が組み込まれています。サポート・プロセスを簡単にするため、IBM 提供の JVM を使用してください。他の JVM 実装では、異なる ORB が使用されます。IBM ORB は、IBM 提供 の Java 仮想マシンと共にしか提供されていません。WebSphere eXtreme Scale には、操作する作業 ORB が必要です。WebSphere eXtreme Scale は、他のベンダーの ORB と一緒に使用できます。ただし、ベンダー ORB で問題が発生した場合は、その ORB ベンダーにサポートを依頼する必要があります。IBM ORB 実装 は、サード・パーティーの Java 仮想マシンと互換性があり、必要な場合は置換できます。

orb.properties のチューニング

研究所では、最大 1500 の JVM のデータ・グリッドで以下のファイルが使用されました。 orb.properties ファイルは、ランタイム環境の lib フォルダーにあります。
# IBM JDK properties for ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# WS Interceptors
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# WS ORB & Plugins properties
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Needed when lots of JVMs connect to the catalog at the same time
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Clients and the catalog server can have sockets open to all JVMs
com.ibm.CORBA.MaxOpenConnections=1016

# Thread Pool for handling incoming requests, 200 threads here
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# No splitting up large requests/responses in to smaller chunks
com.ibm.CORBA.FragmentSize=0