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