wrapper.cpu.timeout プロパティ
対応バージョン :2.2.8
対応エディション :プロフェッショナル版スタンダード版コミュニティー版
対応プラットフォーム :WindowsMac OSXLinuxIBM AIXFreeBSDHP-UXSolarisIBM z/Linux

警告

このプロパティの説明を読まずに、パラメーターを変更することは絶対にしないで下さい。 設定を間違えると、期待どおりに動作せず、Wrapper の動作不良や不具合の原因となります。

注意

プロパティ「wrapper.use_system_time=TRUE」に設定されないと、このプロパティは無視されます。

「wrapper.use_system_time=FALSE」の場合、［wrapper.timer_fast_threshold］と［wrapper.timer_slow_threshold］のプロパティを使用して、システム時刻の変更および重負荷の影響での遅延による同様の通知を記録できます。

このプロパティには、JVM が警告を発信してタイムアウト時間を延長する前の、 CPU を利用していない時間数（秒数）を設定します。 このプロパティに効果を持たせるためには、 他のタイムアウトプロパティ （［wrapper.startup.timeout］、［ wrapper.ping.timeout］、［ wrapper.shutdown.timeout］）より下回る値でなければなりません。 プロパティ値を「0（ゼロ）」に設定すると、タイムアウト（時間切れ）の延長は発生しません。

デフォルト値は「10秒」です。

設定例：（10秒） 
wrapper.cpu.timeout=10

もし、Wrapper が延長された時間数の間に「CPU を利用していない」と検知した場合、 下記のような Wrapper や JVM、あるいは両方からのメッセージを目にするかもしれません。

ログ出力の例： 
INFO   | wrapper  | Wrapper プロセスは、27秒間、CPU 時間を何も受信していません。
                    タイムアウトを延長中。
INFO   | jvm 1    | JVM プロセスは、27 秒間、CPU 時間を何も受信していません。
                    タイムアウトを延長中。

このケース例では、これらのメッセージは警告であり、 Wrapper とその JVM プロセスの両方が、27 秒間 CPU へのアクセスが拒否されたことを示しています。 現在の Wrapper の状態次第で、 スタートアップ、ping、あるいは、シャットダウン、どれかのタイムアウトが、 処理力の不足が原因の「FALSE」タイムアウトを避けるために、延長されています。

Wrapper か、コントロールされている JVM か、どちらかが延長された時間数の間に CPU へのアクセスを拒否される原因は、２つのケースが考えられます。 どちらのケースであっても、タイムアウト（時間切れ）が１回か数回か発生しているため、 Wrapper が JVM がハングアップしたと想定して、再起動、あるいはシャットダウンを誘発しています。

これが起こりうる１つ目の可能性は、Wrapper が他のプロセスへ譲歩することなく、 延長された時間数の間、CPU 100％消費をする慣性を持つ他のプロセスと競合して、 システムリソースを奪い合っているときです。 ほとんどの現代の OS では、マルチタスク管理に関して適正に動作しますが、中には失敗するケースもまだあります。 Windows 上でのこの１例をあげると、マシンのメモリが低く、たくさんのディスクスワッピングへ導びく例です。 もし総メモリが十分に大きくない場合、アプリケーションに CPU サイクルが再び与えられる前に、 システム全体が1分間ほどフリーズすることもあります。

CPU タイムアウト問題で悩んでいる場合、ほとんどのケースでは、 このタイムアウト時間を延長するという手法より、CPU を取得できない Wrapper の問題を解決する道を見つけるべきです。 Wrapper によって実行されているアプリケーションが CPU を取得していない場合、 クライアントからの要求を確実に処理することはできません。

２つ目の可能性は、システムが一時停止され、再開するときです。 これはノートブックのパソコンでは一般的なことです。 システムが復帰したとき、システム時間が突然に数時間進んでいるように見えることがあります。

デフォルトでは、警告メッセージは、10秒後に表示されます（実際にはかなり長く感じます）。 トリガーされた CPU タイムアウトは、ログ内に表示されるメッセージ以外のアプリケーション上で何も逆効果はありません。 このメッセージがログ記録されるのを避けるためには、大きい値を設定するか、 完全に無効にしてください。

警告

この機能はありますが、このプロパティ値を「0（ゼロ）」（＝タイムアウト無効）または 「他のタイムアウトより大きくい値」を設定すると、 重負荷が発生するケースで、タイムアウトが不正にトリガーされる可能性があることに注意してください。 これは、実際に再起動が必要ない場合にでも、JVM 再起動を誘発することもあります。

参照： タイムアウト（時間切れ）
  • [ wrapper.cpu.timeout ] (2.2.8)

    JVM が警告を発信してタイムアウト時間を延長する前の CPU を利用しない期間（秒数）を設定します。

  • [ wrapper.max_hostid_timeout ] (3.4.0) ( スタンダード版/プロフェッショナル版 )

  • [ wrapper.logfile.close.timeout ] (3.5.21)

    最後のログエントリの後にログファイルを閉じる秒数を制御します。

  • [ wrapper.logfile.flush.timeout ] (3.5.21)

    Wrapper がすべての出力ログをログファイルにフラッシュ（書き出し）する間隔を秒単位で設定します。

  • [ wrapper.logfile.inactivity.timeout ] (3.2.0 - 3.5.21で廃止)

    最後のログ記録の後に、ログファイルが閉じられるまでの秒数を制限します。

  • [ wrapper.ping.timeout ] (1.0.0)

    JVM から送信される ping 応答の最大間隔（秒数）を設定します。

  • [ wrapper.startup_thread.timeout ] (3.5.11)

    非同期スタートアップ処理を完了させるための待機時間（秒数）を設定します。

  • [ wrapper.startup.timeout ] (1.0.0)

    Wrapper が JVM プロセスを起動してから、JVM 側がアプリケーションのスタートアップが確立したと応答を返すまでの Wrapper の待機時間（秒数）を設定します。

  • [ wrapper.shutdown.timeout ] (2.2.7)

    Wrapper が JVM へシャットダウンするように指示を出してから、JVM 側がそれに応答して停止すると返事するまでの待機時間（秒数）を設定します。

  • [ wrapper.jvm_exit.timeout ] (2.2.8)

    「JVM が停止している」とレポートを受けてから、実際に JVM プロセスを終了するまでの待機時間（秒数）を設定します。

  • [ wrapper.jvm_cleanup.timeout ] (3.4.0)

    JVM が完全にシャットダウンされた後、Wrapper が子プロセスをクリーンアップする最大時間（秒数）を設定します。

  • [ wrapper.jvm_terminate.timeout ] (3.5.18)

    Wrapper がシステムに JVM プロセスの強制終了を要求してから終了したことを確認するまでの秒数を設定します。