| 対応バージョン : | 2.2.8 |
| 対応エディション : |    |
| 対応プラットフォーム : |          |
|
警告
|  |
このプロパティの説明を読まずに、パラメーターを変更することは絶対にしないで下さい。
設定を間違えると、期待どおりに動作せず、Wrapperの動作不良や不具合の原因となります。
|
このプロパティには、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 Process has not received any CPU time for 27 seconds.
Extending timeouts.
INFO | jvm 1 | JVM Process has not received any CPU time for 27 seconds.
Extending timeouts.
|
このケース例では、これらのメッセージは警告であり、
Wrapper と JVMプロセスの両方が、27秒間CPUへのアクセスが拒否されたことを示しています。
現在のWrapperのステート（状態）次第で、
スタートアップ、ping、あるいは、シャットダウン、どれかのタイムアウトが、
処理力の不足が原因の「FALSE」タイムアウトを避けるために、延長されています。
これには２つのケースが考えられ、
Wrapperか、コントロールされているJVMか、どちらかが、
延長された時間数の間に、CPUへのアクセスを拒否されています。
どちらのケースであっても、タイムアウト（時間切れ）が１回か数回か発生しているため、
WrapperがJVMがハングアップしたと想定して、再起動あるいはシャットダウンを誘発しています。
これが起こりうる1つ目の可能性は、
Wrapperが他のプロセスへ譲歩することなく、
延長された時間数の間、CPU100％消費をする慣性を持つ他のプロセスと競合して、
システム・リソースの奪い合いっているときです。
ほとんどの現代のOS（オペレーティング・システム）では、
マルチタスク管理に関して適正に動作しますが、中には失敗するケースもまだあります。
Windows上でのこの１例をあげると、マシンのメモリが低く、たくさんのディスク・スワッピングへ導びく例です。
もし総メモリが十分に大きい場合、
アプリケーションが再びCPUサイクルを取得する前のほんの１分間、
システム全体がフリーズすることもあります。
CPUタイムアウト問題に悩んでいる場合、ほとんどのケースでは、
このタイムアウト時間を延長するという手法ではなく、
CPUを取得できないWrapperの問題を解決する道を見つけるべきです。
そもそもWrapperによって動かされているアプリケーションがCPUを取得しない場合、
クライアントからのリクエストを確実にサービスを提供することができないでしょうから。
２つ目の可能性は、もしシステムがサスペンドされレジューム（再開）していることです。
これはノートブックのパソコンでは一般的なことです。
システムが復帰したとき、システム時間が突然に数時間進んでいるように見えることがあります。
デフォルトでは、警告メッセージは、10秒後に表示されます（実際にはかなり長く感じると思います）。
トリガーされたCPUタイムアウトは、
ログ内に表示されているメッセージ以外のアプリケーション上で何も逆効果はありません。
タイムアウトがログ記録されたこのメッセージを避けるためには、大きい値を設定するか、完全に無効にしてください。
|
警告
| |
この能力が有効中の場合、
このプロパティ値を「0 (ゼロ)」（＝タイムアウト無効）か、あるいは「他のタイムアウトより大きくい値」を設定すると、
重い負荷が発生するケースで、タイムアウトが不正にトリガーされる可能性がある、
ということに注意してください。
これは、本当に再起動が必要ない場合にでも、JVM再起動を誘発します。
|
|
