mod_rails(passenger)はmogrelの3倍メモリを食う？

　Rails運用時で気になるのは、安定性とパフォーマンス。安定性はいろいろ負荷テストをして時間が経たないと分からないので、まずはメモリのパフォーマンスから調べてみます。

　とりあえず、ちょっとしたサンプルをmongrelで動かしてみると、44Mほどメモリを確保しています。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
1003     14412  0.0  2.2  44316 23556 ?        Sl   Apr10   0:01 /usr/bin/ruby1.8 /var/lib/gems/1.8/bin/mongrel_rails start

　んで、同じプロセスをmod_rails(passenger)で起動すると、143Mほど確保されます。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     23423  0.0  0.5  21720  9172 ?        Sl   06:24   0:00 Passenger spawn server                                                                                                                          
root     25426  9.0  1.2  34796 20944 ?        S    17:01   0:00 Passenger FrameworkSpawner: 2.0.2                                                                                                               
1000     25427  4.1  1.2  43204 22560 ?        S    17:01   0:00 Passenger ApplicationSpawner: /u/app/test/releases/20080413134312                                                   
1000     25429  0.3  1.2  43288 22316 ?        S    17:01   0:00 Rails: /u/app/test/releases/20080413134312      

　まだ詳しく追ってないんですが、”Passenger spawn server”は、Apache起動時に同時に起動されるプロセスで、Apache稼働中は常駐しています。これは稼働しているアプリの数に関わらず1個です。

　Railsアプリがインストールされているアドレスにアクセスすると、Railsアプリのプロセスが起動されます。
“FrameworkSpawner”がgemにインストールされたRails本体です。これは同じバージョンのRailsを使っていれば、複数プロセスで共有されます。
　”ApplicationSpawner”と”Rails”が、プログラム本体です。想像ですが、”ApplicationSpawner”は待機中のプロセスで、”Rails”が稼働中のプロセスの様です。負荷が増えた場合は、”ApplicationSpawner”をcloneして起動するんじゃないかと思います。

　そして、一定時間(RailsPoolIdleTimeで指定した値、デフォルトで120秒)、アプリへのアクセスがないと、”ApplicationSpawner”と”Rails”は終了させられます。少し遅れて”FrameworkSpawner”も終了される様です。終了しないかも。

　なので、一つのサーバでさほどアクセスのないアプリを多数上げる場合には、mod_railsが向いているようです。１つのサーバで複数のアプリは上げない、メモリを余計に食いたくないというときは、mongrelの方が良いかもしれません。

　ただ今のマシンはメモリが多いので、この程度は気にしなくても良いかもしれませんが。