Apache 2.2 の internal dummy connection の謎

linux

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）を処理し自分で死ぬ。

なんかどうでもいいやって結論でした（ｗ

とゆことで

  • mod_proxy 関連はたぶん関係ない。
  • 現状だと prefork MPM のみ。worker ではでない。experimental な event MPM でもでないと思う。
  • 上記「プロセスが再生成されるあたりのタイミング」は正しいといえば正しいけど正確じゃない。正確には「子プロセスが殺されるあたりのタイミング」。