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 https://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 https://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.
Awesome! Now I don’t have to do it 😉
Pingback: Dreamhost, Rails and locally installed Gems » CRAZ8
Great idea!
Can’t tell if it works yet, but surely it’s a well-needed plugin! Thanks for contributing!
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 ##
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?
Pingback: Rails Deployment » Blog Archive » Dreamhost Deployment
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:
=> 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?
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
Yeah, I think the easiest solution will be to keep the plugin off the local machine, too. Thanks for the follow up!
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….
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).
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.
Has anyone figured out anything similar to this now that Dreamhost is using Passenger?
Andrew W.
Pingback: Capistrano 2 Recipe for Dreamhost Shared Hosting and mod_rails | Encounters with the World Wide Web