複数の処理でTomcatが停止する

Javaのシステムを運用しています。
1台のサーバー（CentOS5.0)に、Apache－Tomcat5.0－PostgreSQL8.1－アプリケーション（顧客ごと（10社））がインストールされています。
アプリケーションの切り分けはTomcatのconf/catalina/localhost/コンテキスト.xml で定義しています。（コンテキスト１～１０を作成）

昨年秋から以下の障害が発生していますが、未だに原因がわからない状況です。
Javaの知識、Tomcatの知識、PostgreSQLの知識など乏しく、ログも取れていない状況です。
どうか、疑わしい原因、調査方法など教えていただきたく存じます。

障害状況
日付　　現象　　　　　　　　　　　　　　　　　　　　　　　　　回復
11/6 A画面でB画面への遷移ボタンをした時に　　　Tomcat再起動し、再実行したところ
　　　　　サーバーのB画面作成処理が中断　　　　　　　正常に処理できた。
11/16 TOPメニューからC画面を選択したが、　　　　　約10時間後、中断していたC画面処理
　　　　　サーバーのC画面作成処理が中断　　　　　　　が再開された。その後正常に処理。
12/26　 D画面でE画面への遷移ボタンをした時に　　　Tomcat再起動し、再実行したところ
　　　　　サーバーのE画面作成処理が中断　　　　　　　正常に処理できた。
1/6　　 F画面でG画面への遷移ボタンをした時に　　　Tomcat再起動し、再実行したところ
　　　　　サーバーのG画面作成処理が中断　　　　　　　正常に処理できた。
1/8　　 F画面でH画面への遷移ボタンをした時に　　　　約45分後、中断していたH画面処理
　　　　　サーバーのH画面作成処理が中断　　　　　　　が再開された。その後正常に処理。
　　　　　・他のユーザーがその顧客のシステムを
　　　　　使うと、E画面処理、G画面処理、H画面
　　　　　処理で中断する。
　　　　　・他の顧客のシステムは、同じ処理を行
　　　　　っても正常に処理できる。（レスポンス
　　　　　も正常）

中断した処理では、データベースのアクセスは読込み（SELECT文）のみです。
プログラムではThreadクラスは使っていません。
Tomcatの設定でセッションタイムアウト時間を無制限（-1）に設定していました。
Tomcatの設定でコネクションプールの最大値は100に設定しています。
障害発生時は、ログインユーザーは一人だけでした。

その後、GCログの出力、ヒープメモリ使用状況のログ出力、PostgreSqlのログ出力の設定を行いました。
また、セッションタイムアウト時間を30分に設定しました。

本日（1/29）まで障害は発生しておりません。

よろしくご教授ください。

No.3 回答者： sech1152 回答日時： 2014/01/31 16:13

単純な発想として、コネクションの閉じ忘れとかは無いですか?

コネクションの管理を、自前でやっているのか、フレームワークを利用しているのかで違ってくると思いますので、もしかしたら関係ないかもしれませんが…。
（私も、開発中に時々やってしまいます。まったく反応がなくなり、なんでだ？となり、調べてみると閉じ忘れていた。）

障害発生時のコネクション数を確認してみてはどうでしょうか？
あるいは、障害が発生していなくても、コネクション数が予想より多くないかとか。
ただ、起動時にいきなり最大数を確保してしまうようになっていると、見分けがつかないかもしれません。

コネクションを閉じ忘れていても、Tomcatを再起動すれば、コネクションが一旦解放されます。（同時に、ロックも解放されると思います。）

この回答へのお礼

ご回答ありがとうございます。

私も最初にコネクションのClose漏れを疑いました。
テスト環境にて、コネクションプールを1個ににてテストしましたが、Close漏れはありませんでした。

以前、Close漏れがあったときは、
SQLNestedException: Cannot get a connection, pool exhausted
が発生しエラーログが出ました。

今回はエラーログは何も出ません。
PostgreSQLからの応答をずっと待っているように見えます。

よろしくお願いします。

お礼日時：2014/01/31 18:39

No.2 回答者： teketon 回答日時： 2014/01/31 03:17

同時にPostgreSQL8.1を使ったユーザーは居ない、ということで予想は外れてます。

もしも使ったユーザーがいれば、ツールの使用等によりロック処理をしていれば、
10時間後にロック解除することで11/16日のように処理が進むかなと予想しました。

システムが発行するクエリにロックを掛けるようなものはないのでしょうか？

この回答への補足

ご回答をいただきましてありがとうございます。

現象から見ると、DBの特定のテーブルにロックがかかっていて、ロックが解除されるまで待っているように見えます。
調べましたところ、PostgreSQLはSELECT文でもロックがかかるそうです。

現象が発生した処理では、SELECT文だけです。しかも、データ量も少なく、1秒もかからない処理です。

利用ユーザーは1人でデッドロックがかかることは考えにくいのです。

他に、ロックが解除されない状況というものが発生することがあるのでしょうか。

よろしくご教授ください。

補足日時：2014/02/03 13:50

この回答へのお礼

teketonさん、ご回答ありがとうございます。

システムが発行するクエリにロックを掛けるようなものはありません。
システム以外では、毎夜、1：02から、バックアップ取得、バキューム、リインデックス処理を行っていますが、同じ時刻には障害は発生していません。

PostgreSQLはSELECT文だけでもロックがかかるという記事を見つけました。
http://d.hatena.ne.jp/chiheisen/20100310/1268238 …

この現象の原因になりうるでしょうか。

また、ロックが原因と仮定したとき、Tomcatの再起動でロックが解除されるものでしょうか。

お考えをお聞かせください。
よろしくお願いします。

お礼日時：2014/01/31 11:00

No.1 回答者： teketon 回答日時： 2014/01/30 02:23

DBにロックがかかったのでは？

該当時間帯にDBを使用していたユーザはTomcatからのみでしょうか。
DBを直接参照していたり、バッチが動いていたりとか。

この回答への補足

ご回答ありがとうございます。

障害発生時の状況は、DBのロックがかった状態と思えますが、
Tomcatを再起動することでロックが解除できるのでしょうか。
また、放置した状態で、１０時間後、ロックが解除されることがあるのでしょうか。

teketonさんのお考えをお聞かせください。

よろしくお願いします。

補足日時：2014/01/30 11:16

この回答へのお礼

ご回答ありがとうございます。

該当時間帯にDBを使用していたユーザーは、Tomcatからのみです。
バッチ処理は行っていません。

よろしくお願いします。

お礼日時：2014/01/30 09:45