|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
|
|
|
WebOTX Manual V10.3 (第4版) 目次を表示 |
JMSのチューニングについて説明します。ここでは、主に、メッセージの滞留に関するチューニングポイントについて説明しています。
以降の説明で、「設定方法」には、設定対象となる統合運用管理ツール上の項目名や、MOの属性名を記述しています。設定方法の詳細については、 [ JMS > JMSサービスの操作 ] を参照してください。
JMSサーバの設定について説明します。
JMSサーバにおけるJVMヒープの最大サイズは、デフォルトで192Mバイトに設定されています。通常、大量のメッセージ送受信でJMSサーバに負荷がある場合は、JVMヒープサイズを大きくする必要があります。
JMSサーバのJVMヒープの消費は、主にJMSサーバ内に滞留するメッセージの数とサイズに比例します。システムの運用上想定している数のメッセージが滞留した場合に、 どの程度のメモリが消費されるかを確認して十分なヒープサイズを設定することが必要になります。また、逆にシステムのリソースに合わせて、後述する設定を行うことにより滞留自体を抑止することも有効です。
JVMヒープ内のその時点での総メモリ量と、使用可能な空きメモリ量は、JMSサーバに関する統計情報から確認できます。
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> get --monitor=true server.jms-service.MemoryTotal-Count空きメモリ量
otxadmin> get --monitor=true server.jms-service.MemoryFree-Count
統計情報取得に必要な設定などの詳細については、マニュアル [ JMS > JMSサービスの統計情報取得 ] を参照してください。
必要な値を設定し、 JMSサーバを再起動してください。
統合運用管理ツールで設定する場合：
運用管理コマンドで設定する場合：
otxadmin> set server.jms-service.vmargs=<JavaVM引数>
例)
統合運用管理ツールでの指定 ： -Xms128 -Xmx384
運用管理コマンド ：
otxadmin> set server.jms-service.vmargs=”-Xms128 -Xmx384”
JDBCストア利用時に、送信先にメッセージが大量に蓄積されていると、JMSサーバの起動に時間がかかり、JMSサーバの起動に失敗する場合があります。
この場合、ドメイン起動におけるJMSサーバ起動完了待ち時間を長くする必要があります。
JMSサーバの起動に要する時間は、環境によって異なりますが、参考となる値は${INSTANCE_ROOT}/logs/jmq/jmqserver.logから調べることができます。
ログレベルがデフォルトのINFOである場合、
2017-09-22 21:33:42,176 [INFO] ================================================================== WebOTX JMQ NEC Corporation. バージョン: 10.10.0000 コンパイル: Thu 09/07/2017 11:35:11 ==================================================================
が起動開始を示し、
2017-09-22 21:33:46,238 [INFO] [B1039]: Broker "jmqbroker@xxx.xxx.xxx.xxx:9700" ready.
が起動完了を示しますので、それぞれの先頭で出力されているタイムスタンプから、起動に必要となる時間を算出してください。
設定した値は、次回のドメイン起動から有効になります。
統合運用管理ツールで設定する場合：
運用管理コマンドで設定する場合：
otxadmin> setserver.jms-service.init-timeout-in-seconds=<起動完了待ち時間>
物理的な送信先の設定について説明します。
JMSサーバに必要以上にメッセージを滞留させないためには、メッセージを生成するプロデューサ数を制限することも有効な方法です。
送信先の現在のプロデューサ数は、次の操作で確認できます。
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> get-jmsdest-info <送信先名>
上記の操作で表示される、「Current Number of Producers」の値が現在のプロデューサ数です。
操作の詳細については、マニュアル [ JMS > 送信先の操作 > 情報取得 ] を参照してください。
統合運用管理ツールで設定する場合：
運用管理コマンドで設定する場合：
otxadmin > set server.jms-service.jms-physical-destitination.<送信先名>.maxNumProducers=<プロデューサの最大数>
複数のキューコンシューマが送信先のメッセージを処理する効率は、ここで説明するアクティブコンシューマ数と、JMSサーバが一度の処理でコンシューマに配信するメッセージ数(「メッセージ滞留抑止の設定」参照)によって左右されます。
効率よくメッセージを処理するためには、十分な数のアクティブコンシューマがメッセージの配信に遅れずに対応する必要があります。メッセージがキューに蓄積している場合、メッセージを処理するアクティブコンシューマ数が不十分であることが考えられます。
送信先に対する現在のアクティブコンシューマ数は、次の操作で確認できます。
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> get-jmsdest-info <送信先名>
上記の操作で表示される、「Current Number of Active Consumers」の値が現在のアクティブコンシューマ数です。
操作の詳細については、マニュアル [ JMS > 送信先の操作 > 情報取得 ] を参照してください。
統合運用管理ツールで設定する場合：
運用管理コマンドで設定する場合：
otxadmin > set server.jms-service.jms-physical-destitination.<送信先名>.maxNumActiveConsumers=<アクティブコンシューマの最大数>
JMSサーバが一度の処理でコンシューマに配信するメッセージ数が大きすぎる場合、メッセージがコンシューマ上で滞留する可能性があります。
たとえば、コンシューマへのフロー制限数が大きすぎると、ある一つのコンシューマがキュー内のすべてのメッセージを受信し、そのほかのコンシューマは何も受信していないことがあります。コンシューマの処理が高速であれば、これは問題になりませんが、コンシューマでの処理に時間がかかるような場合、メッセージを各コンシューマに均等に分散させるために、コンシューマへのフロー制限数を小さくする必要があります。
コンシューマでの滞留もメモリ消費につながるため、クライアントのJVMヒープサイズと合わせてフロー制限数を調整する必要があります。
統合運用管理ツールで設定する場合：
運用管理コマンドで設定する場合：
otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.consumerFlowLimitNum=<コンシューマへのフロー制限数>
ただし、各コンシューマが使用するコネクションファクトリで指定された制限値の方が小さい場合は、その値のほうが優先されます。
送信先のメッセージ滞留を抑止するために、送信先単位、または、JMSサーバ全体でメッセージ数とメッセージの合計サイズを設定できます。送信先のメッセージ数、または、メッセージのバイト数が設定された制限に達した場合の動作は、次のものから選択することができます。
| 動作 | 説明 |
| REMOVE_OLDEST | もっとも古いメッセージを削除する。 |
| REMOVE_LOW_PRIORITY | メッセージの有効期間に従いもっとも優先度の低いメッセージを削除する。 |
| FLOW_CONTROL | プロデューサとの間でフロー制御が行われ、プロデューサがブロックされる。 |
| REJECT_NEWEST | 新しいメッセージを拒否する。永続メッセージの場合はメッセージ拒否の例外をスローする。 |
送信先に設定されている制限到達時の振る舞いは、以下で確認できます。
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin > get server.jms-service.jms-physical-destitination.<送信先名>.limitBehavior
送信先、または、JMSサーバ全体の現在のメッセージ数とメッセージのバイト数を監視するには、統合運用管理ツールから参照できる統計情報を利用します。
送信先の場合は、 [ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ 統計情報 ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ 送信先名 ] - [ <送信先名> ] 、JMSサーバ全体の場合は、 [ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ 統計情報 ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] の「統計情報採取開始」を実行します。
送信先
JMSサーバ全体
統計情報取得に必要な設定などの詳細については、マニュアル [ JMS > 送信先の操作 > 情報取得 ] を参照してください。
送信先ごとのメッセージ滞留抑止に関する値は、以下で設定します。
統合運用管理ツールで設定する場合：
メッセージの最大数
[ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ 送信先名 ] - [ <送信先名> ] - [ 拡張 ] - [ メッセージの最大数 ]
メッセージの最大サイズ
[ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ 送信先名 ] - [ <送信先名> ] - [ 拡張 ] - [ メッセージの最大合計サイズ ]
制限到達時の振る舞い
[ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ 送信先名 ] - [ <送信先名> ] - [ 拡張 ] - [ 制限到達時の振る舞い ]
運用管理コマンドで設定する場合：
メッセージの最大数
otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.maxNumMsgs=<メッセージの最大数>
メッセージの最大サイズ
otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.maxTotalMsgBytes=<メッセージの最大合計サイズ>
制限到達時の振る舞い
otxadmin> set server.jms-service.jms-physical-destitination.<送信先名>.limitBehavior=<制限到達時の振る舞い>
JMSサーバ全体のメッセージ滞留抑止に関する値は、以下で設定します。
統合運用管理ツールで設定する場合：
メッセージの最大数
[ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ JMSサーバ情報 ] - [ JMSサーバ内メッセージ最大数 ]
メッセージの最大サイズ
[ WebOTX管理ドメイン [ <ホスト名> ] ] - [ <ドメイン名> ] - [ アプリケーションサーバ ] - [ JMSサービス ] - [ JMSサーバ情報 ] - [ JMSサーバ内メッセージ最大合計サイズ ]
運用管理コマンドで設定する場合：
メッセージの最大数
otxadmin> set server.jms-service.systemMaxCount=<JMSサーバ内メッセージ最大数>
メッセージの最大サイズ
otxadmin> set server.jms-service.systemMaxSize=<JMSサーバ内メッセージ最大合計サイズ>
コネクション関連の設定について説明します。
WebOTX JMQは、サーバとクライアント間の相互通信にTCP/IPプロトコルを利用していますが、データ受信を主体としている場合、ネットワークの異常を検知できないような事象（簡単な例だと、 相手側のケーブルが抜けたような場合）が発生する場合があり、次のような問題を引き起こす可能性があります。
JMSサーバが、クライアントの異常を検知できずに、クライアントに関するリソースがパージできない。
JMSクライアントが、サーバの異常を検知できずに、メッセージ配信を待ちつづけてしまい、JMSサーバのクラスタ切り替えに対応できない。
このような問題を防ぐために、クライアントアプリケーションのライブラリレベルで、JMSサーバとの接続を定期的にチェックする機能を提供しています。
この機能はデフォルトで動作しますが、監視間隔は任意の値に変更することができます。
JMSサーバに対する設定は、次のプロパティが対象になります。
起動引数として設定する方法と、config.propertiesファイルに設定する方法とがあります。設定方法や設定値の詳細については、 [ コンフィグレーション(設定一覧) > JMS > JMS設定項目・設定方法 ] をご覧ください。
起動引数
統合運用管理ツールの場合：
-Dwojms.ping.enabled=true -Dwojms.ping.interval=120
運用管理コマンドの場合：
setコマンドで以下の設定を行ってください。
otxadmin> set server.jms-service.start-args=” -Dwojms.ping.enabled=true -Dwojms.ping.interval=120”
config.properties
ファイルに以下の設定を行ってください。
コネクションファクトリリソース
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> set server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsPingInterval=<接続監視の間隔>
プロデューサからのメッセージ送信に対して、JMSサーバが受諾通知を返すようになっているときに、JMSサーバへの負荷が高い場合や、ネットワークの通信速度が遅いような場合、 プロデューサが受諾通知を受け取るまでに時間がかかることがあります。このような場合、デフォルトでは、JMSサーバから受諾通知が届くまで、プロデューサの呼び出しスレッドはブロックするようになっています。
この、受諾通知を待ち合わせる時間は、コネクションファクトリのwojmsAckTimeout(通知タイムアウト)で決めることができます。デフォルトでは、タイムアウトせず、必ず待ちあわせる設定になっています。
受諾通知を待ち続けるのではなく、決められた時間以内に届かないときにはエラーを発生させたい場合、この値を設定してください。
コネクションファクトリの現在の通知タイムアウト値は、以下で確認できます。
コネクションファクトリリソース
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> get server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsAckTimeout
コネクションファクトリリソース
統合運用管理ツールの場合：
運用管理コマンドの場合：
otxadmin> set server.resources.jms-resource.jms-connection-factory.<コネクションファクトリ名>.wojmsAckTimeout=<通知タイムアウト>
JMSクライアントについてのチューニング情報採取について説明します。ここで採取した情報から、クライアント側にメッセージが滞留することによるメモリ負荷の状況を把握することができます。
まず、JMSサーバ側で提供する情報によって、どのJMSクライアントに問題がありそうかを把握し （ [ JMSサーバ側での情報採取 ] ）、 その後、問題のありそうなJMSクライアント側で情報を採取する （ [ JMSクライアント側での情報採取 ] ） という手順になります。
JMSサーバ側ではコネクション単位にメモリ情報を採取し、コネクション一覧で採取した情報を表示します。
統合運用管理ツールで設定する場合：
以下の属性をチェックします。
運用管理コマンドで設定する場合：
otxadmin> set server.jms-service.enableClientMetrics=true
コネクション単位に次の情報を採取します。
| 項目 | 説明 |
| Max Memory | JavaVMの最大メモリ量(バイト数)。 |
| Current Memory | JavaVMの総メモリ量(バイト数) |
| Peak Memory | JavaVMのメモリ最大使用量(バイト数) |
採取された情報は、以下の操作で確認できます。
統合運用管理ツールで確認する場合：
運用管理コマンドで確認する場合：
otxadmin> list-jms-connections
JMSクライアント実行時にJavaシステムプロパティを設定することにより、メモリ状況や、フロー制御に関する項目をログ出力することが可能です。
コネクションファクトリのwojmsConsumerFlowLinit(滞留可能なメッセージ数の制限値)や、wojmsConsumerFlowThreshold(配信を再開するポイント)、 JMSクライアントのメモリサイズの決定には、ここで採取できる情報も参考になります。
JMSクライアントのJavaシステムプロパティとして、以下の値を指定します。
| プロパティ | 設定値 |
| wojms.client.metrics | true |
| wojms.client.metrics.interval | 例） 10000
省略可能。デフォルト値は、5000（ミリ秒）。 |
| wojms.client.metrics.log | 例）C:\client.log
省略可能。ログファイル名を指定しない場合は、標準出力に表示。 |
プロパティの詳細については、 [ コンフィグレーション(設定一覧) > JMS > JMS設定項目一覧 > JMSのプロパティ／属性一覧 ] をご覧ください。
ログに出力する情報は次のとおりです。
メモリ状況に関する項目
| 項目 | 説明 |
| TotalMemory | JavaVMの総メモリ量(バイト数) |
| FreeMemory | JavaVMの空きメモリ量(バイト数) |
| PeakMemory | JavaVMの最大使用メモリ量(バイト数) |
コンシューマレベルのフロー制御に関する項目
| 項目 | 説明 |
| Count of unprocessing | コンシューマで未消費のメッセージ数 |
| Peak count of unprocessing | コンシューマ起動後の未消費メッセージ数の最大値 |
| Pause count | 停止した回数 |
| Resume count | 配信再開要求(RESUME_FLOW)を行った回数 |
| Last resume count | 最後の配信再開要求(RESUME_FLOW)で、JMSサーバに要求したメッセージ数 |
コネクションレベルのフロー制御に関する項目
| 項目 | 説明 |
| Count of unprocessing | コネクションで未消費のメッセージ数 |
| Peak count of unprocessing | クライアントが起動後の未消費メッセージ数の最大値 |
| Pause count | 停止した回数 |
| Resume count | 配信再開要求(RESUME_FLOW)を行った回数 |
コンシューマレベルでは、コンシューマ単位に滞留可能なメッセージ数の制限値(wojmsConsumerFlowLimit)と、配信を再開するポイント(wojmsConsumerFlowThreshold)をコネクションファクトリに設定してフロー制御を行っています。
クライアントへ送信されたJMSメッセージ数が、wojmsConsumerFlowLimitに達すると、JMSサーバはメッセージの配信を停止し、未消費メッセージ数がwojmsConsumerFlowThreshold(%)を下回ると配信を再開します。 配信再開後、JMSサーバから送信されるメッセージ数は、「wojmsConsumerFlowLimit - (コンシューマで未消費のメッセージ数)」となります。
1つのコンシューマでは、最大、「Peak count of unprocessing」×(1メッセージのサイズ)のメモリが滞留メッセージによって消費されることになります。「Peak count of unprocessing」の値を参考に、コネクションファクトリのwojmsConsumerFlowLimitの値や、コンシューマ数、メモリサイズを調整します。
また、「Pause count」は、wojmsConsumerFlowLimitの値に達して停止した回数を示し、「Resume count」は、wojmsConsumerFlowThresholdを下回って、配信を再開する要求を行った回数になります。受信したメッセージ数と比較して、「Pause count」や、「Resume count」の値が大きい場合は、wojmsConsumerFlowLimitが小さすぎるか、wojmsConsumerFlowThresholdが大きすぎて、スループットを低下させている可能性があるため、これらの値を調整する目安とします。
コネクションレベルでは、同一コネクション上のすべてのコンシューマで滞留可能なメッセージ数の制限値(wojmsConnectionFlowLimit)をコネクションファクトリに設定してフロー制御を行います。 ただし、このフロー制御は、wojmsConnectionFlowLimitEnabledがtrueのとき行われ、デフォルトでは制御を行わない(false)設定になっています。
コンシューマ数が決まっていないような場合は、コネクションレベルでの制御が有効です。
コネクション上のすべてのコンシューマの未消費メッセージがwojmsConnectionFlowLimitを超えると、合計数がコネクションの制限を下回るまで、コネクション経由のメッセージ配信を停止します。
コネクションレベルで制御を行っている場合は、1つのコネクションについて、最大、「Peak count of unprocessing」×(1メッセージのサイズ)のメモリが滞留メッセージによって消費されることになります。「Peak count of unprocessing」の値を参考に、メモリサイズの調整を行ってください。