MCやRSが意図せず再起動する

フォローする

システム構成ではRSの下位にWrapper プログラムが存在し、死活監視のために定期的にRSとの通信を試みています。
RSからの応答が一定時間(デフォルトでは30秒間)ない場合、WrapperプログラムはRSがハングアップ しているとみなし、強制的にRSに対して再起動を実施します。※Start Management Consoleで起動したMCも同様

この場合、下記のような問題が発生する可能性があります。

   ・MCの応答がなくなる(Start Manegement Consoleで起動した場合)
   ・スケジュール実行の結果が「No Runs*」となり、ロボットのスケジュール実行がスキップされる   ・RSの強制再起動により、MCの「ログ(Logs)」タブに開始時刻のみ(終了時刻が空白)のデータが
    発生する


RSからの応答がない原因としては下記の2つが考えられます。

   ・常設コネクションが切断されている
   ・RSの負荷が大きい


原因の詳細は下記を確認してください。

■常設コネクションが切断されている

死活監視の通信は常設コネクションにより実施されているため、何らかの理由で外部から常設コネクションが切断された場合、MCやRSの意図しない再起動が発生することがあります。
その際、WrapperログのログレベルがDebug以上であれば、Wrapperログに下記例のようなメッセージが出力されます。RSやMCの自動再起動が頻発する場合、RoboServer.confもしくはWindowsサービスに設定されているWrapperログのログレベルをINFO(デフォルト)からDebugに変更し、同様のメッセージ出力があるかご確認ください。

<例>エラーメッセージ(日本語)

INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager デバッグ: バックエンドソケットを閉じました: java.net.SocketException: Connection reset
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager デバッグ: バックエンドハンドラから戻りました。
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager デバッグ: バックエンドソケットを閉じています。
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager エラー: バックエンドが予想外に閉じられました。再起動してWrapperと再同期します。

 <例>エラーメッセージ(英語)

INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager Debug: Closed backend socket: java.net.SocketException: Connection reset
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager Debug: Returned from backend handler.
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager Debug: Closing backend connection.
INFO | jvm * | 2019/10/23 12:19:29 | WrapperManager Error: The backend was closed unexpectedly. Restart to resync with the Wrapper.


なお、上記のメッセージ出力例はあくまでコネクション切断が検知された際の受動的なメッセージであるため、製品側からコネクションが切断された理由を確認する事は困難である事を予めご了承ください。

 ■RSの負荷が大きい

実行しているロボットがサーバ負荷の高いものである場合、RS自体には異常 がなくても、強制的に RS を再起動してしまうため、実行中のロボットも強制終了されてしまい、結果として MC の Logs 上に開始時刻のみ(終了時刻が空白)のデータが発生してしまいます。

 例として、Wrapperログに下記のようなログが出力されている場合、RSが高負荷の状態である可能性があります。※Wrapperログのログレベルが「INFO(デフォルト)」の場合に出力されるメッセージですが、高負荷状態の場合に必ず出力されるものではありません。

<例>Wrapperログ 

STATUS | wrapper | 2019/03/02 13:35:30 | Pinging the JVM took ** seconds to respond.
STATUS | wrapper | 2019/03/02 13:35:30 | Pinging the JVM took ** seconds to respond.
STATUS | wrapper | 2019/03/02 13:35:30 | Pinging the JVM took ** seconds to respond.
STATUS | wrapper | 2019/03/02 13:35:30 | Pinging the JVM took ** seconds to respond.

 

 この現象は以下の様な条件時に発生することがあります。

  ・「繰り返し(Repeat)」ステップ -「次へ(Next)」ステップ を使用して、
    大量のページを繰り返す処理が組み込まれているロボットの実行時 (※1)

  ・繰り返し大きなページを読み込むロボットの複数台および並行実行時 (※2)

  ・ある程度大量のメモリを積んでおり、
   1回当たりのGC(ガベージコレクション)にかかる時間が長時間に及んだ時

対応策として、下記の2つのうちいずれかが有効です。

  ・メモリの増強
   ※GC(ガベージコレクション)ではなくメモリ不足によるスラッシングが懸念される場合

  ・Wrapper プログラムによる強制再起動の判定時間の延長(※3)

 

注意事項

・Tomcat構築でのMCの意図しない再起動は本ナレッジには該当しません。

・(※1)「タグ繰り返し(For Each Tag)」ステップ等の同一ページ内で繰り返されるものと異なり、
 「繰り返し(Repeat)」ステップ -「次へ(Next)」ステップでページ間を繰り返す場合、ロボットは
 スタックの中にループの情報をキャッシュするため、繰り返し回数によっては大量のメモリを
 使用してしまいます。

・(※2)大きなページとは、HTMLファイル自体の容量だけではなく、大量の外部リンクファイルの
 読み込み処理を行うロボットです。

・(※3) Wrapperプログラムによる強制再起動の判定時間の延長方法は
 『Wrapperプログラムによる強制リブートまでの無反応時間を延長させる』を参照してください。

0人中0人がこの記事が役に立ったと言っています

コメント

0件のコメント

記事コメントは受け付けていません。