Apache 2.2 の internal dummy connection の謎
ab でパフォーマンステストを行っていたんですが,ログに
GET / HTTP/1.0" 200 643 "-" "Apache/2.2 (internal dummy connection)
みたいなのがたまに出現してました。prefork mpm を使っているんですが, MaxRequestsPerChild でプロセスが再生成されるあたりのタイミングですかね(違うかも)。言及されているページがあまりないので謎のままです。一応実害はないらしいですが。
追記
2006年07月28日 id:naoya [apache] 同じく謎。mod_proxy_balancer の live check 用リクエストかなと思ってたんだけど。
あー,そういえば mod_proxy 使ってました。でも実際どうなんだろ。ということで,今日マスターアップを終えてちょい暇になったのでソースを追いかけてみました。
- Apache 2.2 から graceful-stop ができた。
- その絡みでサーバの子プロセスを安全に shutdown する仕組みができた。
- それが pipe-of-death (pod)。親が子に氏ねっていう仕組み(パイプ)。
- 各 MPM で pod を自力で実装することもできるし mpm_common.c の pod を使うこともできる。
- mpm_common.c の pod では子プロセスに氏ねっていった後に dummy_connection を行う(後述)。
- prefork MPM では AP_MPM_USES_POD を #define してるんで mpm_common.c のを使う。
- worker MPM では自力で実装してる。
- なんでとりあえず prefork MPM について考えますね。
- *** このへんからあやふやになります ***
- 親が子を殺したい。MaxRequestsPerChild 越えたとか MaxSpareServers を越えたとか shutdonw 時とか。
- そんなときは親が子に ap_mpm_pod_signal を使って「氏ね」って言う。
- 子プロセスがクライアントと通信中だったらそれが終わったら ap_mpm_pod_check で自分が殺されたかどうか調べて自分で死ぬ(graceful stop)。
- そじゃなかったら?子は accept して待っている。OS によっては kernel 内でブロッキングしてるかも。
- そういう子プロセスの accept の時間切れまで待つのは悠長。
- だから dummy_connection してやる。すると子は accept からとりあえず抜け,単純なリクエスト(= dummy_connection)を処理し自分で死ぬ。
なんかどうでもいいやって結論でした(w
とゆことで
- mod_proxy 関連はたぶん関係ない。
- 現状だと prefork MPM のみ。worker ではでない。experimental な event MPM でもでないと思う。
- 上記「プロセスが再生成されるあたりのタイミング」は正しいといえば正しいけど正確じゃない。正確には「子プロセスが殺されるあたりのタイミング」。