| Oracle® Coherence開発者ガイド リリース3.6.1 B61368-02 |
|
 前 |
 次 |
Coherenceの最大のパフォーマンスを実現するため、操作環境をテストして調整することをお薦めします。テストの詳細は、第44章「ネットワーク・パフォーマンスのデータグラム・テストの実行」を参照してください。
推奨されるチューニングの対象は次のとおりです。
パケットの損失を最小限に抑えるには、オペレーティング・システムのソケット・バッファを大きくして、ガベージ・コレクション時にJavaアプリケーションが停止している間も受信するネットワーク・トラフィックを処理できるようにする必要があります。Coherenceはデフォルトで、ソケット・バッファに2MBの割当てを試行します。大きなバッファを許容するようオペレーティング・システムが構成されていなければ、Coherenceはより小さなバッファを使用することになります。UNIXのほとんどのバージョンではデフォルトのバッファ制限が非常に小さく設定されていますが、これを少なくとも2MBに増大する必要があります。
Coherence 3.1以降、オペレーティング・システムが最大サイズのバッファの割当てに失敗すると、次の警告メッセージが表示されます。
例45-1 OSが最大サイズのバッファの割当てに失敗したことを示すメッセージ
UnicastUdpSocket failed to set receive buffer size to 1428 packets (2096304 bytes); actual size is 89 packets (131071 bytes). Consult your OS documentation regarding increasing the maximum socket buffer size. Proceeding with the actual value may cause sub-optimal performance.
小さいバッファで操作を実行しても安全ですが、より大きなバッファを許容するようオペレーティング・システムを構成することをお薦めします。
Linuxの場合(rootとして実行):
sysctl -w net.core.rmem_max=2096304 sysctl -w net.core.wmem_max=2096304
Solarisの場合(rootとして実行):
ndd -set /dev/udp udp_max_buf 2096304
AIXの場合(rootとして実行):
no -o rfc1323=1 no -o sb_max=4194304
|
注意: AIXでは、1MB、4MBおよび8MBのバッファ・サイズの指定のみサポートされます。さらにIBMのJVM 1.5では、64Kを超えるソケット・バッファを割り当てられないという問題があります。この問題は、IBMの1.5 SR3 SDKで解決されています。 |
Windowsの場合:
Windowsにはデフォルトのバッファ・サイズ制限はありません。
その他:
その他のオペレーティング・システムにおけるバッファ・サイズの増大については、該当するオペレーティング・システムのドキュメントを参照してください。
パケット・パブリッシャおよびユニキャスト・リスナーに異なるバッファ・サイズをリクエストするようCoherenceを構成するには、coherence/cluster-config/packet-publisher/packet-buffer/maximum-packets要素およびcoherence/cluster-config/unicast-listener/packet-buffer/maximum-packets要素を使用します。詳細は、「packet-buffer」を参照してください。
Linuxには選択可能な高分解能タイムソースがいくつか用意されていますが、残念なことに、最速のタイムスタンプ・カウンタ(TSC)でも常に信頼性があるとはかぎりません。LinuxではTSCがデフォルトで選択され、起動時のチェックで非一貫性が検出されると、より低速で安全なタイムソースへの切替えが行われます。低速なタイムソースでは、問合せの実行にTSCタイムソースの10 - 30倍のコストがかかることがあり、Coherenceのパフォーマンスに多大な影響を与える可能性があります。Coherenceおよび基礎となるJVMでは、オペレーティング・システムで使用しているタイムソースを認識しないことに注意してください。システム・ログ(/var/log/dmesg)をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします。例45-2にタイムソース・ログのサンプルを示します。
例45-2 Linuxタイムソースのログ・メッセージ
kernel: Losing too many ticks! kernel: TSC cannot be used as a timesource. kernel: Possible reasons for this are: kernel: You're running with Speedstep, kernel: You don't have DMA enabled for your hard disk (see hdparm), kernel: Incorrect TSC synchronization on an SMP system (see dmesg). kernel: Falling back to a sane timesource now.
このログ・メッセージは、タイムソースの切替えが、CPU使用率の変動(SpeedStep)、DMAの無効化、またはマルチCPUマシンに対する誤ったTSCの同期化などに起因して発生していることを示しています。前述のメッセージが存在する場合は、システム管理者に問い合せてその原因を特定して修正し、TSCタイムソースを使用可能にすることをお薦めします。Linuxの以前のバージョンの一部では、マルチプロセッサ・システムの非同期TSCに関連する不具合があります。この不具合の結果として、クロックが急に4398秒進んだすぐ後に正しい時刻に戻る場合があります。この不具合によって、ノードがクラスタから不適切に削除されるという結果をもたらす誤ったCoherenceパケット転送タイムアウトがトリガーされる場合があります。4398秒のタイムアウトの警告とともにクラスタの切断が生じた場合は、Linuxカーネルをアップグレードすることをお薦めします。このようなログ警告の例を次に示します。
A potential communication problem has been detected. A packet has failed to be delivered (or acknowledged) after 4398 seconds ...
Linux TSCに関するこの問題の詳細は、次のリソースを参照してください。
Microsoft Windowsでは、小さなデータグラムの送信時に使用される高速IOパスがサポートされます。小さいと見なされるデータグラムのデフォルト設定は1024バイトです。この値をネットワークMTUに合せて増大すると(通常は1500)、ネットワーク・パフォーマンスが著しく向上する可能性があります。
このパラメータを調整する手順は次のとおりです。
レジストリ エディタを実行します(regedit)。
レジストリ・キーHKLM\System\CurrentControlSet\Services\AFD\Parametersを見つけます。
新しいDWORD値(Name: FastSendDatagramThreshold、Value: 1500(decimal))を追加します。
再起動します。
|
注意: Coherence 3.1以降には、前述の変更を自動的に実行するoptimize.regスクリプトが含まれています(インストールのcoherence/binディレクトリ)。スクリプトを実行したら、コンピュータを再起動して変更を有効にする必要があります。 |
このパラメータの詳細は、http://technet.microsoft.com/en-us/library/bb726981.aspxの「Appendix C」を参照してください。
Windows(NT、2000、XPを含む)は、デスクトップ・アプリケーションの使用に合せて最適化されます。2つのコンソール(DOSボックス)ウィンドウを開くと、その他のプロセスに優先度の高い実行中のスレッドがあっても、フォーカスのある1つのコンソールがCPUのほぼ100%を使用してしまうことがあります。このアンバランスを修正するには、フォアグラウンド・アプリケーションが軽量で動作するようにWindowsのスレッド・スケジューリングを構成する必要があります。
「コントロール パネル」を開きます。
「システム」を開きます。
「詳細設定」タブを選択します。
「パフォーマンス」の「設定」を選択します。
「詳細設定」タブを選択します。
「プロセッサのスケジュール」で「バックグラウンド サービス」を選択します。
|
注意: Coherenceには、前述の変更を自動的に実行するoptimize.regスクリプトが含まれています(インストールのcoherence/binディレクトリ)。 |
スワップ領域を頻繁に使用しないよう、マシンには十分なメモリーを搭載してください。スワップ率を監視するには、vmstatやtopなどのツールを使用します。スワップ領域を介して頻繁に移動が発生していると、Coherenceのパフォーマンスに大きく影響する可能性があります。また、スワッピングによってスワップ・アウトされることで長時間レスポンスがなくなり、そのマシン自体がクラスタから削除されているCoherenceノードとして示されることもあります。
ネットワーク・カード(NIC)が最大リンク速度および全二重で動作するよう構成されていることを確認します。この確認処理はオペレーティング・システムにより異なります。
Linuxの場合(rootとして実行):
ethtool eth0
インタフェース設定の調整方法および詳細は、ethtoolのmanページを参照してください。
Solarisの場合(rootとして実行):
kstat ce:0 | grep link_
これにより、インタフェース0のリンク設定が表示されます。重要な項目はlink_duplex(全二重は2)とlink_speed(Mbps単位)です。
Windowsの場合:
「コントロール パネル」を開きます。
「ネットワーク接続」を開きます。
目的のネットワーク・アダプタの「プロパティ」ダイアログを開きます。
「構成」を選択します。
「詳細設定」タブを選択します。
「リンク速度とデュプレックス」でドライバ固有のプロパティを見つけます。
このプロパティを「自動検出」または特定のリンク速度とデュプレックスに設定します。
1Gb/秒以上のPCIネットワーク・カードでは、システムのバス速度がネットワークのパフォーマンスを制限する要因になることがあります。PCIおよびPCI-Xバスは半二重で、すべてのデバイスはそのバス上のデバイスの最低速度で実行されます。標準のPCIバスには最大約1Gb/秒のスループットがありますが、全二重の1GbのNICを使用してそのスループットを実現することはできません。PCI-Xにはさらに高い最大スループットがありますが(1GB/秒)、バス上に低速のデバイスが1つでもあるとそれが足かせとなります。満足な双方向のデータ・レートを実現できない場合は、マシンのバス構成を評価することをお薦めします。たとえば、NICをプライベート・バスに再配置するだけでパフォーマンスが向上する場合もあります。
複数のクラスタ・ノード間で数秒間にわたる通信の停止が頻繁に発生する場合は、スイッチのバッファ領域の増大が必要になることがあります。このような通信の停止は、ローカルまたはリモートのGCに起因しない、複数ノードでの通信の遅延を特定する一連のCoherenceログ・メッセージにより特定できます。
例45-3 通信の遅延を示すメッセージ
Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2006-10-20 12:15:47.511, Address=192.168.0.10:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512
Cisco 6500シリーズなどの一部のスイッチでは、各イーサネット・ポートまたはASICで使用可能なバッファ領域の容量を構成できます。負荷の高いアプリケーションでは、デフォルトのバッファ領域の増大が必要になる場合があります。Ciscoでこれを実現するには、次を実行します。
fabric buffer-reserve high
この設定の詳細は、Ciscoのドキュメントを参照してください。
全二重イーサネットにはフロー制御機能があります。これにより、固定リンクの受信側に合せて送信側の速度を低下させることができます。これは、受信側からイーサネットPAUSEフレームを送信側に送信することで実行できます。PAUSEフレームで指定された期間、送信側は送信を停止します。この停止により、負荷の高くないマシンに送信するトラフィックも含め、送信側のすべてのトラフィックがブロックされます。これには行頭ブロック条件が含まれる場合があります。その場合、スイッチ上に過負荷のマシンが1つあると、その他すべてのマシン速度が実質的に低下します。ほとんどのスイッチ・ベンダーは、スイッチ・リンク間のイーサネットのフロー制御を無効にして、多くてもマシンに直接接続されているポートでのみ使用することを推奨しています。この設定でも行頭ブロックは発生する可能性があるため、イーサネットのフロー制御はすべてまとめて無効にすることをお薦めします。TCP/IPやCoherence TCMPなどのより高いレベルのプロトコルには、行頭ブロックの影響を受けず、低レベルのフロー制御も必要としない独自のフロー制御メカニズムがあります。
この問題の詳細は、http://www.networkworld.com/netresources/0913flow2.htmlを参照してください。
Coherenceはデフォルトで1500バイトのネットワークMTUを想定し、その想定に基づいて、1468バイトのデフォルトのパケット・サイズを使用しています。パケット・サイズがMTUを満たさないと、ネットワークは有効に活用されません。機器で異なるMTUを使用する場合は、ネットワーク・パスの最小MTUよりも32バイト小さいパケット・サイズを指定してCoherenceを構成します。パケット・サイズはcoherence/cluster-config/packet-publisher/packet-size/maximum-lengthおよびpreferred-length構成要素で指定できます。これらの要素の詳細は、「packet-size」を参照してください。
ノード間の完全なパスを経由する機器のMTUが不明な場合は、標準のpingやtracerouteユーティリティを使用して特定できます。MTUを特定するには、2つのマシン間で一連のpingまたはtraceroute操作を実行します。それぞれの試行において、最初は大きいパケット・サイズを指定し、断片化されずにパケットが処理されるようになるまで徐々に値を下げていきます。入念に確認を行ったパケット・サイズを指定し、パケットが断片化されないようにする必要があります。
Linuxの場合、次を実行します。
ping -c 3 -M do -s 1468 serverb
Solarisの場合、次を実行します。
traceroute -F serverb 1468
Windowsの場合、次を実行します。
ping -n 3 -f -l 1468 serverb
その他のオペレーティング・システムについては、ドキュメントでpingまたはtracerouteコマンドについて調べて、断片化の回避方法を考慮した上でパケット・サイズを指定してください。
パケットを断片化する必要があるというメッセージが出力される場合、指定したサイズはパスのMTUより大きいことになります。断片化せずにパケットを送信できるサイズがわかるまでパケット・サイズを小さくしていきます。1468より小さいパケットを使用する必要がある場合は、MTUを少なくとも1500まで増大するようネットワーク管理者に問い合せてください。
この項で示す推奨事項は、一般的な使用の場合には十分で、必要な設定作業は最小限です。JVMのサイズ設定時に考慮すべき第一の問題は、使用可能なRAMとガベージ・コレクション(GC)一時停止時間とのバランスです。
キャッシュ・サーバー
Coherenceキャッシュ・サーバーについての標準的で安全な推奨事項として、固定のヒープ・サイズを1GB以下にして実行することをお薦めします。また、増分ガベージ・コレクタを利用して、GC一時停止時間を最小限に抑えることをお薦めします。最後に、JVMコマンドラインで-serverを指定して、すべてのCoherence JVMをサーバー・モードで実行することをお薦めします。これにより、長期間稼働するアプリケーションにいくつかの点で最適なパフォーマンスが得られます。
例:
java -server -Xms1g -Xmx1g -Xincgc -Xloggc: -cp coherence.jar com.tangosol.net.DefaultCacheServer
このサイズ設定では、より詳細なJVMチューニングの必要がなく、適切なパフォーマンスが得られます。ガベージ・コレクションの詳細は、「GCの監視と調整」を参照してください。
|
注意: もっと大きなヒープ・サイズを指定してキャッシュ・サーバーを実行することも可能ですが、GC一時停止を最小限に抑えるにはJVMの監視とチューニングがより重要になります。スクラッチ領域の容量を増やしてGCの圧縮がより迅速になるように、記憶域の比率の変更が必要になる場合もあります。また、大きなサイズのヒープの管理が大幅に向上するHotSpot 1.6など最新のJVMバージョンを利用することをお薦めします。「ヒープ・サイズに関する考慮事項」を参照してください。 |
キャッシュ・クライアント
長時間稼働するGCが原因で、Coherence TCMPクライアントが停止しているとの誤認識が生じる可能性があるため、Coherence TCMPクライアントも同様にサーバーをキャッシュするように構成する必要があります。
Extendクライアント
専門的に言えば、Coherence Extendクライアントはクラスタ・メンバーではなく、このため、長時間稼働するGCからの影響が小さいです。Extendクライアントの場合、Coherenceの埋込み先のアプリケーションで説明されているとおりに既存のガイドラインに従うことをお薦めします。
この項の内容は、次の項目を決定する際に役立ちます。
システムに必要なCPUの数
各システムに必要なメモリーの量
システムごとに実行するJVMの数
JVMごとに構成するヒープのサイズ
すべてのアプリケーションがそれぞれ異なるため、この項をガイドラインとしてよく読む必要があります。適切な構成を選択するために次の質問に対する答えが必要になります。
Coherenceキャッシュに格納することになるデータの量はどのくらいか。
待機時間とスループットに関するアプリケーション要件は何か。
アプリケーションはどれくらいCPUまたはネットワーク集中型か。
サイズ設定は、あいまいな科学と言えます。パフォーマンスおよび負荷の頻繁なテストに代わるものはありません。
この項は、次のトピックで構成されています。
固定サイズのヒープを使用して実行すると、必要に応じてJVMでヒープを増大する必要がなくなり、パフォーマンスが向上します。固定のヒープ・サイズを指定するには、JVMオプションの-Xmsと-Xmxを同じ値に設定します。例:
java -server -Xms4G -Xmx4G ...
1つのJVMプロセスでは、指定されているヒープ・サイズより多くのシステム・メモリーが消費されます。ヒープ・サイズ設定によって、JVMでアプリケーションに使用できるヒープの量が指定されますが、JVM自体もさらにメモリーを消費します。消費される量は、オペレーティング・システムおよびJVM設定によって異なります。たとえば、Linuxで実行している1GBのJVMで構成されたHotSpot JVMでは、約1.2GBのRAMが消費されます。JVMのメモリー使用量を外部で測定して、RAM負荷率が大きくなりすぎないようにすることが重要です。topやvmstatなどのツール、およびタスク・マネージャは、実際に使用されているRAMの量の特定に便利です。
記憶域の比率
指定したサイズのキャッシュ・サーバー内に格納できるデータの量として、プライマリ・キャッシュ記憶域のヒープの3分の1以下に使用を抑えることを基本的にお薦めします。これによって、次の3分の1をバックアップ記憶域に、最後の3分の1をスクラッチ領域に割り当てることができます。スクラッチ領域は、クラスの保持、一時オブジェクト、ネットワーク転送バッファ、GC圧縮などに使用します。<high-units>要素を構成して、<unit-calculator>要素にBINARY値を指定することによって、キャッシュごとにプライマリ記憶域を制限するようCoherenceを設定することができます。これらの設定は、バックアップ記憶域にも自動的に適用されます。
プライマリ記憶域とバックアップ記憶域の両方が、JVMに確保されている領域内に収まることが望ましいです(HotSpotベースのJVMの場合)。コレクタ生成のサイズ設定の詳細は、次のHotSpotのガベージ・コレクションのチューニング・ガイドを参照してください。
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
キャッシュ・トポロジとヒープ・サイズ
大きなデータセットでは、パーティション・キャッシュまたはニア・キャッシュを使用することをお薦めします。パーティション・キャッシュのスケーラビリティは読取りと書込みの両方において線形であるため、Coherence JVMの数が変動しても、キャッシュのパフォーマンスに大きく影響することはありません。レプリケーション・キャッシュを使用すると、GCに対する負荷がきわめて大きくなります。
システムごとに実行するJVMの数の決定
システムごとに実行するJVM(ノード)の数は、システムのプロセッサ/コア数とメモリー量によって異なります。まず、2つのコアごとに1つのJVMを実行する計画から始めることをお薦めします。この推奨内容によって、次の要素のバランスが取れます。
サーバーごとに複数のJVMを使用することによって、Coherenceでネットワーク・リソースをより効率的に使用できるようになります。Coherenceのpacket-publisherとpacket-receiverでは、JVMごとのスレッドの数が固定されます。コアを追加すると、それらのコア間でスケーラビリティを向上できるようにJVMを追加できます。
JVMが多すぎると、プロセッサでの競合とコンテキストのスイッチングが多くなります。
JVMが少なすぎると、使用可能なメモリーを処理できない場合や、NICを完全に利用できない場合があります。
特に、大きなヒープ・サイズの場合、JVMには、長時間のGC休止を避けるための処理能力が必要です。
アプリケーションに応じて、1つのコアにつき1つになるまでJVMを追加できます。推奨されるJVMの数と構成されたヒープ・サイズも、ソケットごとのプロセッサ/コアの数とマシンのアーキテクチャによって異なる場合があります。
ヒープのサイズ設定
ヒープ・サイズを検討する際は、適切なバランスを見つけることが重要です。下限はJVMごとのオーバーヘッドによって(または潜在的に数が増大する可能性のあるJVMの管理のしやすさによっても)決まります。たとえば、インフラストラクチャ・ソフトウェア(JMXエージェント、接続プール、内部JVM構造など)に100MBの固定オーバーヘッドがある場合、ヒープ・サイズが256MBのJVMを使用すると、非キャッシュ・データのオーバーヘッドは約40%になります。JVMヒープ・サイズの上限はメモリー管理のオーバーヘッドによって決まります。特に、GCの最大一時停止時間やGCに割り当てられているCPUの割合(およびその他のメモリー管理タスク)によって決まります。
GCは次の項目に影響を及ぼす可能性があります。
Coherenceに対する操作の待機時間。ヒープが大きいほど、小さいヒープより待機時間が長くなり、予測が難しくなります。
クラスタの安定性。非常に大きいヒープの場合、JVMはGC一時停止の間は応答しなくなるため、非常に長いガベージ・コレクション休止によって、クラスタ・メンバーが停止しているとTCMPが誤認識する可能性があります。TCMPではメンバーの状態を判断する際にGC一時停止が考慮されますが、ある時点でそのメンバーは停止していると判断される場合があります。
次のガイドラインをお薦めします。
Sun 1.5 JVMの場合、それぞれにつき１GBおよび2GBを超えるヒープを割り当てないようにすることをお薦めします。
Sun 1.6 JVMまたはJRockitの場合は、ヒープの割当てを4GB以下に抑えることをお薦めします。また、SunのConcurrent MarkおよびSweep GCまたはJRockitのDeterministic GCの使用をお薦めします。
GC一時停止の長さは、ヒープ・サイズに比例した割合より長くなります。つまり、ヒープ・サイズが2倍になると、一般的にGCによる一時停止時間は2倍より長くなります。GC一時停止は、アプリケーション使用状況の影響も受けます。
ヒープ内のライブ・データ量が増すにつれ、一時停止時間が長くなります。ヒープ内でライブ・データが70%を超えないようにすることをお薦めします。これにはプライマリ・データ、バックアップ・データ、インデックス、およびアプリケーション・データが含まれます。
オブジェクト割当て率が高いと一時停止時間が長くなります。それぞれのネットワーク・パケットで多くのオブジェクトが生成されるため、単純なCoherenceアプリケーションでさえ、オブジェクト割当て率が高くなる場合があります。
CPU集中型の計算によって、競合が増え、一時停止時間が長くなる場合もあります。
待機時間の要件に応じて、前述で推奨した値より大きいヒープ領域を割り当てることができますが、必ずシステムの負荷テストを実行してください。
パーティション・キャッシュの記憶域に専用のCoherenceキャッシュ・サーバー・インスタンスを使用すると、データがローカルに保存されなくなるため、アプリケーションJVMのヒープ・サイズが最小限に抑えられます。大半のパーティション・キャッシュ・アクセスはリモートで実行される(データの1/Nのみがローカルに保持される)ので、専用キャッシュ・サーバーを使用しても、通常は追加のオーバーヘッドはあまり増大しません。ニア・キャッシュ・テクノロジを使用することもできます。このテクノロジは、通常、ヒープ・サイズに最小限の影響しか及ぼしません(パーティション・キャッシュよりもさらに小さなサブセットをキャッシュするためです)。多くのアプリケーションでヒープ・サイズを著しく減らし、応答性を改善できます。
ローカルのパーティション記憶域は、tangosol.coherence.distributed.localstorage Javaプロパティ(-Dtangosol.coherence.distributed.localstorage=falseなど)を使用して有効化(キャッシュ・サーバーの場合)または無効化(アプリケーション・サーバーの場合)できます。
また、tangosol-coherence.xml(またはtangosol-coherence-override.xml)ファイルの<local-storage>設定を次のように変更して無効化することもできます。
例45-4 パーティション記憶域の無効化
<!--
Example using tangosol-coherence-override.xml
-->
<coherence>
<cluster-config>
<services>
<!--
id value must match what's in tangosol-coherence.xml for DistributedCache
service
-->
<service id="3">
<init-params>
<init-param id="4">
<param-name>local-storage</param-name>
<param-value system-property="tangosol.coherence.distributed.
localstorage">false</param-value>
</init-param>
</init-params>
</service>
</services>
</cluster-config>
</coherence>
記憶域が無効なクライアントがキャッシュにアクセスする前に、記憶域が有効なJVMが少なくとも1つ起動している必要があります。
長いGC休止時間は、Coherenceクラスタに悪影響を及ぼす可能性があり、ほとんどの場合ノードの停止と区別できません。GCの休止時はJavaアプリケーションでパケットを送受信できず、受信側のオペレーティング・システムではバッファリングしたパケットが破棄され、再送信が必要になる場合があります。このため、GC一時停止時間が最小限になるようにクラスタ・ノードのサイズを設定、調整することが重要です。一般的に、ノードの停止時間のうちGCによるものを10%未満に抑え、通常のGC一時停止時間を100ミリ秒未満に抑え、最大のGC一時停止時間を1秒ぐらいにすることが必要です。
GCアクティビティは、様々な方法で監視できます。いくつかの標準的なメカニズムを次に示します。
JVMスイッチ-verbose:gc
JVMスイッチ-Xloggc: (冗長GCと似ていますが、タイムスタンプが含まれます。)
JVMスイッチ-Xprof: (情報のプロファイリングであるアクティビティのプロファイリングは、テストと本番デプロイメントとで区別する必要があり、リソースとパフォーマンスに対するGCアクティビティの影響も監視する必要があります。)
JConsoleなどのツールを介したOver JMX
あるクラスタ・ノードが別のクラスタ・ノードについて一定期間応答のないことを検出した場合、ログ・メッセージが生成されます。このメッセージは一般に、ターゲットのクラスタ・ノードがGCサイクルにあることを示しています。
例45-5 ターゲットのクラスタ・ノードがガベージ・コレクション・モードであることを示すメッセージ
Experienced a 4172 ms communication delay (probable remote GC) with Member(Id=7, Timestamp=2006-10-20 12:15:47.511, Address=192.168.0.10:8089, MachineId=13838); 320 packets rescheduled, PauseRate=0.31, Threshold=512
PauseRateは、統計が最後にリセットされてからノードが応答なしと見なされるまでの時間の割合を示します。稼働時間に対して応答しない時間の割合が数パーセント以上あるとレポートされたノードは、GCのチューニングを調査する必要があります。
Coherenceには、ネットワーク上の送信トラフィック量を調整する構成要素があります。<traffic-jam>および <flow-control>のドキュメントを参照してください。これらの設定は、クラスタ・ノード内またはノード間のパケット・フロー率の制御に使用されます。
前述の設定がパフォーマンスにどれほど影響しているかをチェックするには、クラスタ・ノードにパケットの損失や重複があるかどうかをチェックします。これは、様々なクラスタ・ノード上で次のJMXの統計を確認するとチェックできます。
ClusterNodeMBean.PublisherSuccessRate: 1.0未満である場合は、パケットが失われ再送信されていることがわかります。レートが0.98未満であれば、調査および調整が必要になる場合があります。
ClusterNodeMBean.ReceiverSuccessRate: 1.0未満である場合は、同じパケットが複数回受信されていることになります(重複)。これは、パブリッシャがパケットの損失を過度に申告していることに起因している可能性があります。
ClusterNodeMBean.WeakestChannel: 現在のノードとの通信が最も困難なリモート・クラスタ・ノードを特定します。
JMXを使用したCoherenceの監視については、第34章「JMXを使用したCoherenceの管理方法」を参照してください。
大きなデータセットをキャッシュしている場合、一般には、そのデータセットのほんの一部で大半のデータ・アクセスに対応しています。たとえば、1,000のオブジェクトで構成されるデータセットがある場合、その操作の約80%が100のオブジェクトで構成されるサブセットに対して実行され、残り20%の操作は、その他900のオブジェクトに対して実行されます。言うまでもなく、最も高い投資対効果は、100の最もアクティブなオブジェクトをキャッシュすることで得られます。残り900のオブジェクトをキャッシュすると、さらに25%有効性の高いキャッシングを実現できますが、リソースにおける900%の増大が必要になります。
ただし、すべてのオブジェクトが同頻度でアクセスされる場合(データセットの順次スキャンなど)は、同レベルの有効性を得るためにより多くのリソースが必要になります。この場合、80%のキャッシュの有効性を実現するためには、10%ではなく80%のデータセットのキャッシュが必要になります(部分的にキャッシュされたデータセットの順次スキャンは、通常、MRU、LFUおよびMRU-LFUのエビクション・ポリシーに優先することに注意してください)。実際、ほとんどすべての非統合(ベンチマーク)データ・アクセス・パターンは不規則であるため、データのサブセットをキャッシュすることで処理速度は速くなります。
データのサブセットがアクティブであり、そのより小さなサブセットが特にアクティブである場合は、All無効化方針を指定したニア・キャッシュの使用が非常に有用になることがあります(実際には、これは前述のルールの2層拡張になります)。
Coherenceのニア・キャッシュ・テクノロジでは、特にPresent無効化方針を指定している場合、クラスタノード・アフィニティを透過的に利用します。このトポロジはスティッキーなロード・バランサで使用すると特に有用です。キャッシュのフロント部分がスラッシングされる(キャッシュ・エントリの存続期間が非常に短い)場合、Present無効化方針のオーバーヘッドは(Allに比べて)高くなることに注意してください。これは、キー・レベルのイベント・リスナーの追加/削除のオーバーヘッドがより高いためです。一般にキャッシュはスラッシングしないよう調整されるため、通常は問題にはなりません。
一般には、次のキャッシュ・トポロジと使用例の組合せが最適です。
レプリケーション・キャッシュ: 少量の読取り頻度の高いデータ(メタデータなど)
パーティション・キャッシュ: 大量の読取り/書込みデータ(大きなデータ・キャッシュなど)
ニア・キャッシュ: パーティション・キャッシュに似ていますが、読取り頻度の高い段階的なアクセス・パターン(ホットスポットのある大きなデータ・キャッシュなど)やスティッキーなデータ・アクセス(スティッキーなHTTPセッション・データなど)で使用するとさらに有用です。同期化の方法(失効、非同期、同期)に応じて、最悪の場合のパフォーマンス・レベルは、パーティション・キャッシュと同等のレベルから、それよりも大幅に低いレベルまで変動します。
インターリーブとは、キャッシュへの書込み間に発生するキャッシュの読取り数のことを指します。パーティション・キャッシュはインターリーブの影響を受けません(1:1のインターリーブで設計されているため)。一方、レプリケーション・キャッシュとニア・キャッシュは読取り頻度の高いキャッシュに合せて最適化されるため、読取り頻度の高いインターリーブ(各書込み間に10回の読取りなど)が適しています。これは、これら両方のキャッシュが、後続の読取りアクセス用にデータをローカルにキャッシュするためです。キャッシュへの書込みが行われると、ローカルにキャッシュされているこれらの項目は強制的にリフレッシュされますが、これは(ローカル・メモリー・ヒープからオブジェクトをフェッチするほぼゼロ・コストと比べて)比較的コストのかかる処理です。それでも、ニア・キャッシュ・テクノロジを使用する場合の最悪のパフォーマンス・レベルはパーティション・キャッシュと同レベルであり、パフォーマンス・ロスは最良のシナリオと比較した場合の損失になります。
インターリーブは(間接的にですが)読取り/書込み率に関係することに注意してください。たとえば、1:1の読取り/書込み率のニア・キャッシュでは、処理が非常に高速になるか(すべての書込み後にすべての読取りを実行)、非常に遅くなる可能性があります(1:1のインターリーブで書込みと読取りを交互に実行)。
