クライアント接続数オーバーへの対応 |
統合運用管理ツールで設定する「利用可能な同時接続クライアント数」を越えてクライアントから接続があった
場合、接続を受け付けた直後にサーバ側から切断するためその接続要求は失敗し、COMM_FAILURE:
java.net.SocketException がクライアントに返り、クライアントからのアクセスがエラーとなります(ユーザ実
装による)。
この原因は以下が考えられます。
クライアント接続数オーバが発生した場合、AP サーバへの新たな接続が出来なくなります。またセッショ ンの増大によりファイルディスクリプタ不足などが発生すると予期せぬ事象が発生します。特にリッチクラ イアントの場合は、クライアントの終了のさせ方がまずかったり、ファイアウォールやプロキシサーバによ るセション切断が発生したりするとサーバでセッションの切断を検出できず、本来不要なコネクション(ここ ではゴーストセッションと名づけます)が増大していきます。このため実際に接続しているクライアント数以 上に接続数が増える現象が発生してしまいます。
本障害の場合、以下のメッセージがイベントログ・シスログに出力されます。
UNIX:
OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00201 TERMINAL CONNECTION
REJECTED. PLU:<リスナポート番号> TERMINAL NAME:<端末名> EXCEED MAX TERMINAL NUMBER.
|
OTXM:<システム名>:IIOPLSN_CLS:<プロセスID>: W:1:TPS07-00201 端末からの接続を拒否した。PLU
名:<リスナポート番号> 端末名:<端末名> 理由:最大同時接続数を越えてしまった。
現在の接続されているクライアント数の状況を確認方法については以下の方法があります。
|
現在のWebOTX に接続しているクライアント数を確認することができます。クライアント情報の
StatsHolderMBean(CLIName: tpsystem.ClientSession 運用管理ツール: [統計情報]-[domain]-[TP
システム]-[クライアントセッション])接続クライアント数(connectionNum)のカレント値を参照します。
現在のWebOTX に接続しているクライアントの情報を取得することができます。接続先のIP アドレス
や接続時間なども確認できます。同一のIP アドレスからのセッションが多数存在する場合や異常に
長い接続時間のセッションが存在する場合はゴーストセッションが存在する可能性があります。
運用管理ツールの「TP システム」-「クライアントセッション」を参照します。otxadmin コマンド
(list-tpsystem-clients-status)を使用してコマンドラインから参照することもできます。
OS より提供されているnetstat コマンドにより接続しているセッション数を確認することができます。
netstat -a コマンドで表示されるリストのうちlocal 側のポートがiiop リスナのポートであるものが、現
在WebOTX が接続しているセッションの数です。
${INSTANCE_ROOT}/config/tpsystem/sysmsg.trc で接続、切断履歴を確認してください。
TPS07-00103 で接続、TPS07-00107 で切断が確認できます。
また、現在の利用可能な同時接続数の設定を確認する方法は次の通りです。
実際にWebOTX で設定した最大数やOS の制限に達する前に問題を検出する方法としては以下の方法
があります。
統計情報における接続クライアント数の監視
クライアント情報のStatsHolderMBean(CLIName: tpsystem.ClientSession 運用管理ツール: [統計情 報]-[domain]-[TP システム]-[クライアントセッション])接続クライアント数(connectionNum)のカレント 値の閾値上限を設定してモニタリングします。
イベントログ(アプリケーション、システム)・シスログ
${INSTANCE_ROOT}/config/tpsystem/iioplsn.ped
netstat -a の結果
実際にこの現象が発生してしてしまった場合の復旧方法について説明します。
セッションの強制切断
現在接続しているセッションの強制切断を行い、接続数を減らすことができます。状況の確認方法で
も説明していますが、接続時間やクライアントIP アドレスからゴーストセッションが特定できる場合、そ
れに対して強制切断を実施します。
運用管理ツールから「TP システム」-「クライアントセッション」を選択して「クライアントの切断
(disconnection)」を実行してください。otxadmin コマンド(disconnect-cl)を使用してコマンドラインからも
切断できます。
どのセッションを強制切断してよいかが判断がつかない場合は、WebOTX システムの再起動を実施する必要があります。
この問題を予防するための対策については以下の方法があります。
最大接続セッション数の見直し
絶対的にセッション数が不足している場合は、TP システム(tpsystem)のIIOP リスナ(IIOPListener)の「利用可能な同時接続クライアント数」を見直します。
以下の手順で同時接続クライアント数を設定してください。余裕を持たせた値を設定してください。
統合運用管理ツール
[TP システム]-[IIOP リスナ]上限設定タブの「利用可能な同時接続クライアント数」
運用管理コマンド(例)
otxadmin> set tpsystem.IIOPListener.simultaneousConnectionClients=100
未接続状態であっても、「利用可能な同時接続クライアント数」に比例してメモリを消費します。AP が多段構成になっている場合、手前のAP がクライアントとなって「利用可能な同時接続クライアント数」を消化することがあるので、それも考慮する必要があります。
クライアントが接続しっぱなしの場合、運用的に切断してもよいのであれば無通信監視の設定を行ないます。TP システム(tpsystem)のIIOP リスナ(IIOPListener)の以下の設定を見直します。「クライアント制御」の「クライアント無通信監視を行う」をチェックして「クライアント無通信監視間隔」に監視間隔を設定します。
ゴーストセッションが発生していると考えられる場合は、TCP レベルでのキープアライブ設定を有効にすることで、その刈り取りを行うことができます。TP システム(tpsystem)の以下の設定を見直します。「クライアント制御」の「TCP レベルでのアライブチェックを行う」をチェックします。keepalive 機能自体はOS が持つ監視機能となります。WebOTX ではOS のkeepalive 機能使用有無のみを設定します。keepalive 機能のアライブチェック間隔はOS に依存します。
ERROR : org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset vmcid:
0x1000 minor code: 911 completed: Maybe
|
ERROR : org.omg.CORBA.COMM_FAILURE: java.net.SocketException: Connection reset by peer:
socket write error vmcid: 0x1000 minor code: 911 completed: No
|