Ruby on Rails Dreamhost plugin
Update 2/11/07: Just to clarify, this plugin won’t keep your Rails site running on Dreamhost if the sum of all your running processes exceeds 200MB (which is when their process monitor kills your processes). Run ps aux and sum the VSZ column and then divide by 1024. If you’re pushing the limit and are only running one Rails site you may want to look at another provider. If you’re running multiple Rails sites, run each site under a different user (one account can create many users).
Per Thomas Aylott’s suggestion on my previous post Keeping Rails Running at Dreamhost Part 2 I’ve decided to release my Dreamhost signal handling code as a Rails plugin. I’m using it on a Rails 1.2.1 site and a Rails 1.1.6 site.
Here’s the deal:
1. Get your Rails site running on Dreamhost (the wiki should you get you there).
2. Once you’ve got it working, if you experience occasional 500 errors try my signal handling plugin. I still had 500 errors with the frao_handler approach described on the wiki, but if my plugin doesn’t work for you it can’t hurt to try it.
Here’s how to install the plugin:
script/plugin install http://gabrito.com/svn/plugins/dreamhost
With the plugin installed, the dispatch.fcgi will defer exiting when Dreamhost sends your dispatch.fcgi process a TERM signal if it is in the middle of handling a request, otherwise it behaves normally. This has reduced the 500 error rate on my two rails based sites to zero, your mileage may vary though. If you still have problems please don’t comment here and say it doesn’t work, instead figure out the problem and email a patch to thuss [at] gabrito [o] com!
The subversion repo for the plugin is at http://gabrito.com/svn/plugins/dreamhost. If you have other Dreamhost related fixes that make sense for this plugin send them to me and I’ll incorporate them.
February 2nd, 2007 at 10:15 pm
Awesome! Now I don’t have to do it
February 3rd, 2007 at 12:39 am
[...] also added Todd’s new Dreamhost Plugin to the app to help improve [...]
February 3rd, 2007 at 7:57 am
Great idea!
February 14th, 2007 at 7:06 am
Can’t tell if it works yet, but surely it’s a well-needed plugin! Thanks for contributing!
February 14th, 2007 at 11:33 am
I wrote a tiny script that I stuck in my dreamhost account and made executable. This gives me a quick look at my memory usage, but hopefully will work for anyone.
## Begin script ##
#!/bin/sh
TOTAL=0
USER=`whoami | cut -c 1-7`
for i in `ps auwx | grep $USER | awk ‘{ print $5 }’`
do
let “TOTAL = TOTAL + $i”
done
let “TOTAL = TOTAL / 1024″
echo “Memory Usage is $TOTAL”
exit
## End script ##
February 14th, 2007 at 11:41 am
Is there any recommendations for reducing memory usage of a rails app?
I’m having a problem with dreamhost killing my processes for running over the memory limit. My app has 19 controllers with 19 helpers and 20 models. I have 7 plugins too. I could remove 1 controller and model since I recently refactored and removed it’s need.
I am also running edge rails instead of gems since I was developing a RESTful app, but now that 1.2.x is out I don’t need to. Although running “gem list” on dreamhost still states 1.1.6 as the latest gem installed. Would using gems (maybe compiled in my user account folder) reduce memory usage?
February 15th, 2007 at 1:11 pm
[...] Ruby on Rails Dreamhost Plugin [...]
February 28th, 2007 at 1:02 pm
I included this in my app, which I’m deploying to Dreamhost. The app is running fine on Dreamhost with the plugin. Unfortunately I cannot run it locally on Mongrel or WEBrick anymore. I receive the following error:
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
Exiting
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/commands/servers/mongrel.rb:15: warning: already initialized constant OPTIONS
/usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/commands/servers/mongrel.rb:18: undefined method `options’ for []:Array (NoMethodError)
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `gem_original_require’
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:33:in `require’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:495:in `require’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:342:in `new_constants_in’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:495:in `require’
from /usr/local/lib/ruby/gems/1.8/gems/rails-1.2.2/lib/commands/server.rb:39
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require’
from /usr/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:495:in `require’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:342:in `new_constants_in’
from /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.1/lib/active_support/dependencies.rb:495:in `require’
from script/server:3
Any help?
March 4th, 2007 at 5:33 am
bjhess: i had the same problem, you need to delete this plugin on your windows local installation, that is because it uses fcgi.
I tried to install fcgi (gem install fcgi) but it was unsuccessful.
I didn’t know if there is some version of ruby-fcgi for windows available
March 4th, 2007 at 7:25 pm
Yeah, I think the easiest solution will be to keep the plugin off the local machine, too. Thanks for the follow up!
April 1st, 2007 at 11:54 am
and you guys complain about the performance of dreamhost servers? Think about it for a minute — if everyone did this… good way to get your account suspended if support found out about it….
April 7th, 2007 at 8:44 pm
Dude - If you look at this comment:
With the plugin installed, the dispatch.fcgi will defer exiting when Dreamhost sends your dispatch.fcgi process a TERM signal if it is in the middle of handling a request, otherwise it behaves normally.
You’ll see that it *is* being a good neighbor, but AFTER it finished the request, just not in the middle of it. (Assuming of course the code ACTUALLY does what this comment says, I haven’t had any 500’s yet, but I could be back).
April 11th, 2007 at 4:43 pm
Like everyone else that reads this far, I’m using the frao_handler approach on one of the Dreamhost sites I’m developing, and there are still far too many 500’s. I’m wary of the plugin though, because my team develops and deploys using Capistrano, which would make it difficult to keep the plugin off of the dev machines. Would making the code changes directly in dispatch.fcgi (as described before the plugin came out) work? Any advice at all would be appreciated.