MaxRequestsPerChildの謎

投稿者: | 2014年10月11日

CentOSのapache2はデフォルトで prefork mpm である。ブログCMSとしてwordpressを使っているのでサイトにあったパラメータを調整しようと考えた。

ServerLimit の値 ( prefork では「同時クライアント数」の上限が「サーバプロセス数」なので、ここではServerLimit=MaxClientsとしておく) を最大かつサイトに適切であるためにはどうすればいいか、思案した結果、要はhttpdの全プロセスが使うメモリ量が、システムが示している空き実メモリ量を下回ればいいという結論に達した。

フォークされたhttpdのサイズがどれだけなのかチェックしてみた。あちこちに書いているをみると、 MaxRequestsPerChild は値が小さいとプロセスの消滅・生成回数が増えるので処理効率が悪くなり、一方で大きくするとメモリーリークなどをリセットできずプロセスのメモリ量が膨らんでいく、値は両者のトレード・オフで成り立つ、というのが共通の認識のようだ。定性的な説明としては疑問はない。一方で、現代のシステムにおいてはCPUまわりの性能は高く、プロセスの生成と消滅にかかるコストはわずかである。実際に処理速度にどの程度影響を与えるか計測してみた。答えを先にいうと計測の誤差に入ってしまう程度で明確には差はでなかった。

一方で先ほどの2番目のメモリーリークなどをリセットできずにプロセスのメモリ量が膨らんでいく、というデータに関しては明らかな違いがみられた。

結果は予想に反して MaxRequestsPerChild の値が大きい方が、1つのhttpdあたりのメモリ量が減少している。当初考えられていたのとは反対の結果である。

% ab -c 10 -n 100 URL

で取った値であるが、 ServerLimit を32と小さくし、なるべく1つのhttpdが何度も稼働するようにした。 MaxRequestsPerChild と1プロセスあたりの割合は次のとおり。

  • MaxRequestsPerChild,1プロセスあたりの相対メモリ量(64を100とする)
  • 64,100.0
  • 4096,93.4
  • 38400,82.6
  • MaxRequestsPerChild を大きくするにつれ明確に1プロセスあたりの使用メモリ量が減少していた。理由はわからないが先ほどの説明に反する結果となった。

    とりあえず記録として残しておく。