mod_proxy_ajpを使っていて、Too many open filesが出る件。

apache2.2.9 + tomcat6.0.18で裏側にやや重い処理がある。
んで、突然Too many open filesが出たので見てみる。


ulimit -aで見ると
open files (-n) 16384
になっていて、16384までFD数は確保されている。


tomcatプロセスIDを確認して
/proc/[PID]/fd/ | wc -w
でFD数を確認すると16200


なんじゃこりゃ。
そりゃ開けんわ。


/usr/sbin/lsof -p [PID]
tomcatプロセスが使っているFDを確認すると
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
java 22268 tomcat_user 329r 0000 0,8 0 1319567323 eventpoll
java 22268 tomcat_user 354r FIFO 0,7 1319567326 pipe
こんなんがダーっと出てきた。


とりあえずapacheを停止しても、FD数は変わらず。(tomcat側でなんかの処理が溜まってるのかと思ったけどそうではないみたい)
よくわからん。


複数台あるので、一台をtomcat再起動するともちろんFD数は0になる。
でも、apache起動してサービスインさせると、ぐんぐんFD数が伸びてあっという間にToo many open filesに。


http://dev.ariel-networks.com/Members/inoue/tomcat-apache
の記事を見て前々からバグが多いと聞いていたmod_proxy_ajpを疑う。


IOが溜まっているならvmstatでわかるはずだし、ネットワーク経由のデータ連携がボトルネックならnetstatで大量にゴミソケットが出るはず。
でも、今回はない。
そもそも、lsofの結果でFDが329rとか、TYPEが0000とかFIFOとかってなんだかわからん。


とりあえずapacheからのリバースプロキシをajpではなく、httpに変更。
tomcat側もajpで待ち受けてたのをHTTP/1.1に変更。


そしたら解決。
FD数も上昇しないし、もちろんToo many open filesもでない。


推測だけど、mod_proxy_ajpとmod_proxy_httpはコネクションプーリングの実装が違うので、そこらへんのバグがmod_proxy_ajpにあるのかもしれない。
いずれにしても上記ブログ記事の内容を見る限り、ajpを使うメリットもあまりないっぽいので、httpで行こうと思う。