| Oracle Coherence開発者ガイド リリース3.5 B56039-01 |
|
 戻る |
 次へ |
Coherenceの最大のパフォーマンスを実現するため、操作環境をテストして調整することをお薦めします。テストの詳細は、第16章「ネットワーク・パフォーマンスのデータグラム・テストの実行」を参照してください。
推奨されるチューニングの対象は次のとおりです。
パケットの損失を最小限に抑えるには、オペレーティング・システムのソケット・バッファを大きくして、ガベージ・コレクション時にJavaアプリケーションが停止している間も受信するネットワーク・トラフィックを処理できるようにする必要があります。Coherenceはデフォルトで、ソケット・バッファに2MBの割当てを試行します。大きなバッファを許容するようオペレーティング・システムが構成されていなければ、Coherenceはより小さなバッファを使用することになります。UNIXのほとんどのバージョンではデフォルトのバッファ制限が非常に小さく設定されていますが、これを少なくとも2MBに増大する必要があります。
Coherence 3.1以降、オペレーティング・システムが最大サイズのバッファの割当てに失敗すると、次の警告メッセージが表示されます。
例19-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.4.2および1.5では、64Kを超えるソケット・バッファを割り当てられないという問題があります。この問題は、IBMの1.4.2 SR7 SDKおよび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）をチェックして、次のメッセージが記載されていないかどうか確認することをお薦めします。例19-2にタイムソース・ログのサンプルを示します。
例19-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タイムソースを使用可能にすることをお薦めします。
Microsoft Windowsでは、小さなデータグラムの送信時に使用される高速I/Oパスがサポートされます。小さいと見なされるデータグラムのデフォルト設定は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ログ・メッセージにより特定できます。
例19-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コマンドラインで-serverを指定して、すべてのCoherence JVMをサーバー・モードで実行することをお薦めします。これにより、長期間稼働するアプリケーションにいくつかの点で最適なパフォーマンスが得られます。
一般に、ヒープ・サイズを大きくするとガベージ・コレクション時に著しく影響するため、ヒープ・サイズは1GB以下に維持することをお薦めします。1.5以上のJVMではヒープ・サイズを大きくしても問題ありませんが、GCの追加チューニングが必要になることがあります。詳細は、「ヒープ・サイズに関する考慮事項」を参照してください。
固定サイズのヒープを使用して実行すると、必要に応じてJVMでヒープを増大する必要がなくなり、パフォーマンスが向上します。固定のヒープ・サイズを指定するには、JVMオプションの-Xmsと-Xmxを同じ値に設定します。次に例を示します。
java -server -Xms1024m -Xmx1024m ...
JVMプロセスは、指定したヒープ・サイズよりも多くのシステム・メモリーを消費することに注意してください。たとえば1GBのJVMでは1.3GBのメモリーが消費されます。そのため、マシンで稼働するJVMの最大数を決定する場合は、その点を考慮する必要があります。実際に割り当てられているサイズは、topなどのツールを使用して監視できます。ヒープ・サイズの詳細は、「ヒープ・サイズに関する考慮事項」を参照してください。
ガベージ・コレクションが頻繁に発生すると処理が中断されます。これは100ミリ秒以上になることもあり、ネットワークのパフォーマンスに著しく影響します。処理の中断時はJavaアプリケーションでパケットを送受信できず、受信側のオペレーティング・システムではバッファリングしたパケットが破棄され、再送信が必要になる場合があります。
ガベージ・コレクションによる停止の頻度および時間を監視するには、JVMコマンドラインで-verbose:gcまたはcode>-Xloggc:を指定します。
GCのチューニングの詳細は、http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.htmlを参照してください。
Coherence 3.2以降では、あるクラスタ・ノードが別のクラスタ・ノードについて一定期間応答のないことを検出した場合、ログ・メッセージが生成されます。このメッセージは一般に、ターゲットのクラスタ・ノードがGCサイクルにあることを示しています。
例19-4 ターゲットのクラスタ・ノードがガベージ・コレクション・モードであることを示すメッセージ
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>および<burst-mode>のドキュメントを参照してください。これらの設定は、クラスタ・ノード内またはノード間のパケット・フロー率の制御に使用されます。
前述の設定がパフォーマンスにどれほど影響しているかをチェックするには、クラスタ・ノードにパケットの損失や重複があるかどうかをチェックします。これは、様々なクラスタ・ノード上で次のJMXの統計を確認するとチェックできます。
ClusterNodeMBean.PublisherSuccessRate: 1.0未満である場合は、パケットが失われ再送信されていることがわかります。レートが0.98未満であれば、調査および調整が必要になる場合があります。
ClusterNodeMBean.ReceiverSuccessRate: 1.0未満である場合は、同じパケットが複数回受信されていることになります（重複）。これは、パブリッシャがパケットの損失を過度に申告していることに起因している可能性があります。
ClusterNodeMBean.WeakestChannel: 現在のノードとの通信が最も困難なリモート・クラスタ・ノードを特定します。
JMXを使用したCoherenceの監視については、第21章「JMXを使用したCoherenceの管理方法」を参照してください。
