views:

209

answers:

5

I have an apache2 server running Phusion Passenger. On this machine I have two virtual hosts setup each look like this (path's are different for the 2nd virtualhost...but other directives are the same)

ServerName beta.mysite.us DocumentRoot "/var/www/beta/mysite/public"

<Directory "/var/www/beta/mysite/public">
    RewriteEngine on
    AllowOverride All
    Options FollowSymLinks
</Directory>
# http://www.modrails.com/documentation/Users guide.html
PassengerAppRoot "/var/www/beta/mysite"
RailsEnv development
PassengerMaxPoolSize 6
PassengerDefaultUser mysite
# PassengerHighPerformance does come at a trade off of lack of support for mod_rewrite
PassengerHighPerformance off
RailsSpawnMethod conservative
RailsFrameworkSpawnerIdleTime 0
RailsAppSpawnerIdleTime 0
PassengerPoolIdleTime 300

ErrorLog "/var/log/httpd/mysite-beta-error_log"
CustomLog "/var/log/httpd/mysite-beta-access_log" common

Apache starts fine. I can go to one of the virtualhosts and it will load Rails and work. When I go to the second virtualhost, a ruby process spawns ("Rails: /var/www/mysite/current" according to ps awuxf) and uses 100% CPU. This process never exits. At this point neither virtualhost is responsive. If I kill the the offending ruby process, another ruby process replaces it and uses 100% cpu. If I kill these processes about 5-6 times, then both virtualhosts respond but they, are somehow, running the same Rails app?!

I have another virtualhost on this machine that is not setup with phusion passenger..This one never exhibits any problems.

Any help / ideas would be much appreciated!

+1  A: 

Check out this podcast: http://blog.envylabs.com/2009/11/scaling-rails-part-2/

The author introduces 3 useful tools you can use to find any memory leaks in you rails application.

Kieran Hayes
A: 

I would recommend switching to nginx

max ogden
A: 

I had faced similar issues with phusion passenger, with no success in debugging. Later, I switched to apache2+mongrel with mod_proxy. I have seen best stability with nginx though. nginx FTW :)

Nakul
A: 

The obvious thing would be to check you don't have any inadvertent infinite loops or impossible to finish conditions in any of your application. It's all too easy to do a find(:all) by accident on a table too massive to fit in memory.

Does it jam immediately or is there something you must do to trigger it? For example, loading a specific page, or not loading a page at all. There could be something in an initializer that causes trouble.

Being able to power up script/console is always a good sign, especially if you can load records. There's not a lot of information in your description. A copy-paste of the output of 'ps aux' would help.

tadman
A: 

Is it possible you have some code causing this? We have a number of apache/passenger installations. It's more likely something with your code than aapache/passenger.

Michael Doornbos