Home > Tags > mod_rails

mod_rails

[mod_rails]gemsでアプリをインストールしたらApacheの再起動が必要

mod_railsでは、Gemsで新しいパッケージを導入した場合、Apache自体を再起動しないと、アプリからそのパッケージを読み込めない模様。

p.s
 Passenger architectural overviewを見ると大体の構造が分かるみたい。ちゃんと読んでみよう。

 Ruby Enterprise Editionなんかも出る予定なのか。matzの日記で言及されているパッチとかが取り込まれたRubyなのかな?CoWが効くなら、Railsの様なサーバプロセスのメモリ削減には効果的だろうな。

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が向いているようです。1つのサーバで複数のアプリは上げない、メモリを余計に食いたくないというときは、mongrelの方が良いかもしれません。

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

mod_rails用のdeploy.rbとapache用設定ファイルジェネレータ

Railsで一番めんどくさかったアプリの公開を、Apache httpdが動いているサーバに、普通にアップロードするだけで行える様にするモジュール、mod_railsがリリースされました。

いままで似たようなものにmod_rubyがあったのですが、ずっとメンテナンスされていない上に、構造的にRailsには向かないようになっていたので、Phusion社が新しく作ったものです。

日本語での紹介はmoongiftさんの記事をご覧ください。インストール方法や使い方は、こちらの記事を参考にしてください。

このモジュールの評価が高まれば、レンタルサーバでもRailsサポートをしてくれる所が増えるんじゃないかと期待してます。

早速、自分のサーバ(EC2)に入れてみた所、特に問題もなくあっさり動きました。

ただ、Capistranoを使っている場合、mongrelの時のままだと、サーバの起動などで失敗するので、config/deloy.rbをこのようにしました。

同時に、「設定より規約」でWebサーバ設定の自動化をするために、apache2-conf.rbも更新しました
私は、/etc/init.d/apacheの頭の方で、/mnt/www/bin/apache2-conf.rb > /etc/apache2/conf.d/vhosts.conf
を実行させて、apacheのプロセスを操作するたびに、自動生成される様にしています。

これで、ディレクトリ掘って、DB作って、cap deploy:setup; cap deploy:coldするだけで、新しいサーバでRailsのアプリを動かす事ができます。

ずっと作り続けている、Railsサーバの分散環境 on EC2も、これを使おうかと思っているので、ちょっとソースも読んでみます。

p.s
記事内で使っているderivativable.comは、いま作っている途中のcode snippetsサイトです。
投稿されたコードにたいてい、派生物を簡単に作れる様にするのが目標です。
Wikiでも、投稿されたコードを変更できますが、元のコードが消えてしまうので、心理的敷居が非常に高いと思っています。
それに対して、derivativable.comでは、元のコードは消える事なく、その派生物として管理される様になっています。元のコードは、そのまま保存されますので、自分用の変更などを気軽に投稿する事ができます。

まだベータ版にも満たないサービスですが、このコードに自分で機能を加えたときなどは、ぜひ投稿してもらえるとうれしいです。

あと私はデザインができないので、その辺で手伝ってくれる方も大募集。

Home > Tags > mod_rails

Search
Feeds
Meta

Return to page top