メモリ消費量を心配してたけどそれほど大変でもなかった。

  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root     16483  0.0  0.6 123616  6572 ?        Ssl  14:34   0:00 /usr/sbin/httpd
  root     16485  0.0  0.8  14320  8952 ?        S    14:34   0:00 Passenger spawn server
  apache   16490  0.0  1.6  62644 17140 ?        S    14:34   0:26 /usr/sbin/httpd
  apache   16493  0.1  1.6  62600 17188 ?        S    14:34   0:30 /usr/sbin/httpd
  apache   16950  0.0  1.6 103580 17220 ?        S    14:38   0:23 /usr/sbin/httpd
  apache   16491  0.1  1.6  62668 17288 ?        S    14:34   0:30 /usr/sbin/httpd
  apache   16488  0.0  1.6  52420 17300 ?        S    14:34   0:23 /usr/sbin/httpd
  apache   16492  0.1  1.6  62612 17304 ?        S    14:34   0:30 /usr/sbin/httpd
  apache   16954  0.1  1.6 113880 17308 ?        S    14:38   0:32 /usr/sbin/httpd
  apache   17609  0.1  1.6 124116 17432 ?        S    14:45   0:29 /usr/sbin/httpd
  apache   14929  1.0  2.0  27408 21340 ?        S    22:27   0:00 Passenger ApplicationSpawner: /var/www/outdooritem
  root     16602  0.0  2.0  27148 21520 ?        S    14:34   0:01 Passenger FrameworkSpawner: 2.0.2
  apache   13317  2.0  3.6  43168 37308 ?        S    22:02   0:27 Rails: /var/www/outdooritem

稼働してしばらく置いておくと「/usr/sbi/httpd」たちのVSZがものによっては100MB以上とか肥大化しているのでちょっとびびるけど、RSSは安定して20MB以下だしhttpdのプロセスも定期的に生まれ変わるようになっているので問題ないかなと。
Railsと直接関係しない（public以下の静的ファイルの面倒は見てくれるが）httpdプロセスの状況は、VSZが増えて行くところ以外はmod_rails導入前と大して変わらない。
前のエントリではVSZが増えたのをメモリ消費量増えたと表現してた。けどちゃんと見たら実メモリ使用量は大して変わってなかった。もちろんパフォーマンス的にも問題はない。

「Rails: /var/www/outdooritem」は普段はひとつだけど、連続したアクセスが増えてくると現状で数個くらいにまで増える。（デフォルトの状態で最大20個までのようだ）
このプロセスはひとつにつきRSSが35MB～40MB程度なので、プロセスひとつ当たりのメモリ消費はmongrelと比べて少ないくらい。
「Passenger*」たちを加えると1プロセス動作時の実メモリ使用量は若干増えるけど、プロセスが増えるほどmod_railsの方が有利になる。

またmongrelは時間のかかるリクエストを処理している状態で次のリクエストが来ると、前のリクエストが終わるまで次のリクエストを待たせるけど、mod_railsは適宜プロセスを増やして柔軟に対応してくれる。
このあたりはmongrelでクラスター組むよりすぐれている。

Apacheのmod_proxy_balancerと複数のmongrelで組んだクラスターでは、クラスター内のbusyなプロセスにもリクエストを割り振るので時々クライアントを待たせる状態が発生していた。
なのでmongrelを5個くらい立ち上げてごまかしてたんだけど、その状況に比べるとmod_railsを使っている現在の方が断然健全な状態になった。

参考までに実メモリ消費量でざっくり比較すると以下のようなかんじになっていて、メモリ1GBで他にもいろいろとやらせていることのあるマシンではけっこう助かっている。

• mongrel 50MB/process * 5 = 250MB
• Passenger*の合計 50MB + Rails:* 40MB/process * 3 = 170MB

プロセス数が1個の状態で比較するとmongrelの方が40MBくらいお得だけど、mongrelを複数立ち上げてクラスターを組むようならmod_railsの方が楽だし負荷にも柔軟だなぁ。
クラスター内のmongrelに処理を割り振るためにリバースプロキシとか使う面倒もないし。

ちなみに現時点で1日当たりのアクセスは6000～9000リクエスト程度。
Googlebotがスゲーお得意様です。

近況

MarkeZine：◎少年ジャンプの歴代人気キャラが駅貼りポスターで競演、缶コーヒー「ルーツ」キャンペーン

今日たまたまJR町田駅で見かけたが、悟空の言ってることがあまりにローカルネタすぎて吹いたｗ
あなどれねぇぜ町田。

しかし自作のアプリを動かしてみると以下の問題が出た。

• database.ymlの中でMySQLのソケット位置に関するハックが使えない （※環境によっては使えた。不思議）
• BackgrounDrbとの通信がうまくできずサーバーエラーとなる

いずれもちょっと特殊ケースになるのかもしれないが、商用レベルで動かしているアプリケーションを移行する場合はしっかりテストはした方がよいと思われる。
こういう時のテストはSeleniumがよさげだなぁ。

あとメモリの消費量はけっこうでかい。
PHP5込みのApache2で1プロセス当たり30MB程度だったのが50MBにふくれあがった。
mongrelは1プロセス当たり5MBから6MB程度なのでだいぶ違う。 50MBから60MB。桁間違ってた。
これはメモリの貧弱なマシンにはけっこうきついなー。と、間違い分で認識を改めつつもやはりApacheのプロセスがいくつも立ち上がってしまうときついかなぁ。抑制するオプションはあるっぽいけど。

とは言え、Apacheで簡単にRails運用できる意義はやっぱり大きい。
fast-cgiの設定もいらなくなるし、public以下の.htaccessとかいじる必要もなくなるし（.htaccessは明示的に読ませない限り読まれない。読まなくても勝手にmod_railsがよきに計らってくれる）
バーチャルホストを定義するだけでいいというのは本当にお手軽。

GithubのPassengerのプロジェクトを見ると毎日怒濤のコミットがなされているのでbetaが取れる日も遠くはなさそうだ。

参考

Overview — Phusion Passenger (a.k.a. mod_rails)

追記

メモリ関連はそんなに心配するほどでもなかった。

mod_rails安定稼働中 – ひげろぐ