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

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 If you have other Dreamhost related fixes that make sense for this plugin send them to me and I’ll incorporate them.

This entry was posted in Ruby, Ruby on Rails, Systems Administration. Bookmark the permalink.

15 Responses to Ruby on Rails Dreamhost plugin

  1. Awesome! Now I don’t have to do it 😉

  2. Pingback: Dreamhost, Rails and locally installed Gems » CRAZ8

  3. Marze says:

    Great idea!

  4. flevour says:

    Can’t tell if it works yet, but surely it’s a well-needed plugin! Thanks for contributing!

  5. Daniel Lunde says:

    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 ##

    USER=`whoami | cut -c 1-7`

    for i in `ps auwx | grep $USER | awk ‘{ print $5 }’`
    let “TOTAL = TOTAL + $i”

    let “TOTAL = TOTAL / 1024”

    echo “Memory Usage is $TOTAL”

    ## End script ##

  6. Daniel Lunde says:

    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?

  7. Pingback: Rails Deployment » Blog Archive » Dreamhost Deployment

  8. bjhess says:

    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
    => Call with -d to detach
    => Ctrl-C to shutdown server
    ** Starting Mongrel listening at
    ** Starting Rails with development environment...
    /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?

  9. Manuel says:

    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

  10. bjhess says:

    Yeah, I think the easiest solution will be to keep the plugin off the local machine, too. Thanks for the follow up!

  11. observer says:

    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….

  12. why says:

    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).

  13. Marc says:

    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.

  14. Andrew W says:

    Has anyone figured out anything similar to this now that Dreamhost is using Passenger?

    Andrew W.

  15. Pingback: Capistrano 2 Recipe for Dreamhost Shared Hosting and mod_rails | Encounters with the World Wide Web

Comments are closed.