【真夏の夜のミステリー】Tomcatを殺したのは誰だ？ (1/3) - ＠IT

セキュリティ

Tomcatが無応答になったトラブルシュートについてわかりやすく説明された記事です。

まさか、2台のWebサーバーが１５０づつ送ってきて結果３００スレッド必要だった、、、、なんて気づかないですよね。

↓神の一声ｗ

■ 担当者「気になるところがある」

　次の一手を考えあぐねていたところ、ログの整理をしていた担当者からTomcatのログファイルに気になるところがあるとの連絡を受けた。

　早速見てみると、以下のようなメッセージが、問題が発生した時間帯よりちょっと前に、出力されていた。

リスト1　Tomcatのエラーメッセージ
2007/xx/xx xx:28:50 org.apache.tomcat.util.threads.ThreadPool logFull
致命的: すべてのスレッド (200) が現在稼働中で待機しています。maxThreads (200) を増やすか、そのサーブレットのステータスをチェックしてください

　これは、Tomcatの持つスレッドプールが最大スレッド数に達してしまったという内容のメッセージだ。Tomcatは、スレッドの生成／破棄のオーバヘッドを削減するため、スレッドプーリングの機能を持っている。スレッドの数が多過ぎるとサーバ上のリソースを消費し過ぎてしまうため、プールには上限値として最大スレッド数を設定できる。

負荷テストは1台でやっていたから、発生しなかったっての、、、本当にありがちｗ

■ 負荷テストをしていたのに、なぜ問題が発見できなかったのか？
今回のシステムでは冒頭で述べたとおり、試験環境で負荷試験を行っていた。それにもかかわらず、なぜこの問題が発見できなかったのか？
実は、後から分かったことだが、負荷試験の際、APサーバの台数は本番環境と同じ2台用意したが、マシン台数を確保できなかったため、負荷の低いWebサーバは1台で試験を行っていた。そのため、スレッド数は抑えられ、この問題を発見できなかったのだ……

この辺よく読むこと。

■ 【3】mod_jkのタイムアウト値

　mod_jkでは、各種タイムアウト値を設定できる。これらのパラメータを適切に使用すれば、問題発生時に無応答を回避し、フェイルオーバやユーザーにエラーページを返すことが可能となる。

　これらのパラメータについての詳細はmod_jkのドキュメントを参照してほしい。