Dreamhost Rails FCGI Woes
December 7th, 2006
I wouldn’t rate dreamhost’s uptime as amazing but you simply can’t beat it for the price. That said, the past few weeks have been a rails nightmare for me. I couldn’t keep a rails application running on dreamhost to save my life. They were all fine until a few weeks ago. After trading emails with support, we finally figured out what was wrong. My fcgi processes were being killed because I was going over my memory limit.
Ok, this I can deal with. Stupidly, I was running all of my rails apps under one username. A few weeks ago, I added a couple more rails apps, just enough to cause me to hit my limits about every hour and get all my processes killed (which is really frustrating). I immediately moved a couple of the apps to their own usernames and all is well. Over the next few weeks, I’ll move the rest of my rails apps to their own usernames and dreamhost will once again be suitable for my rails hosting. Sweet. Granted only time will tell if this is really the problem, but my apps have been running great for the past 5 hours which is a really long time when compared with how often they were crapping out.
Lesson To Be Learned
Host each rails application on dreamhost with its own username. Don’t try to fit them all in one.
Subscribe
That is really good to know John. Excellent tip. I’ve been considering a move to Media Temple. http://www.mediatemple.net/webhosting/gs/details.htm
What is the memory limit on FCGI processes anyway?
I don’t actually know what the limit is and support didn’t tell me unfortunately. The issue with media temple’s grid servers is that you can’t host very many rails apps unless you bump up your rails container. A 1GB container is an additional $70/month on top of the normal grid price which means you are probably better off getting a VPS or something dedicated. If you are in it for Rails and you need something pretty reliable, your best bet is probably a VPS from slicehost or something.
I’m hoping this is why my dreamhost ror programs are running so strangely. So is the key making different usernames for each domain/subdomain or for each database? And do you have to do anything past changing the username to change the application over and get it running smoothly? Thanks John!
Yes, one username per domain. I wouldn’t run more than 3 or 4 low traffic rails apps on one username. It doesn’t matter if it’s domain or subdomain, what matters is the number of apps per user. I typically create a new user, password and host for each database.
There are some other keys to keeping them running nice such as capistrano for deployment but the main thing I have run into is the memory cap for an individual user.
As far as what it takes to move a site to the new user, you just have to switch it in the dreamhost control panel and then redeploy the files. If you are using capistrano, this only takes a few setting changes. I can switch a capistrano deployed app in about five minutes once all the dreamhost settings update.
If you change users, be sure to change your svn username to the same as the new unix username. In my experience cap on dreamhost runs smoother with svn and unix usernames and passwords that are the same (makes for less configuration).
Another tip from a fellow Dreamhost + Rails customer: separate user names are essential when you need to push out new versions of an app. I use Capistrano to deploy and part of its process is to reap old FCGI processes so that the changes take effect. If you run multiple applications as a single user, all of those applications will be impacted, causing them all to have to spin up again.
I found this out when I deployed to a staging site with the same username, only to find out that my production FCGI processes were getting reaped as well. I quickly moved my staging server to a separate username and I can now deploy to staging as often as I want without disrupting the production version.
@James - Excellent tip. I noticed this happening but hadn’t actually processed what was happening. Makes sense now.
I can’t believe no one’s come across this information before. Awesome. As a DH customer myself I did notice that the shell account that runs a couple of Rails apps ran a lot slower than the one where I was just testing out new code. I proudly thought that it was my much improved coding skills [which I’m still gonna chalk it up to] but now I know there may be other circumstances. Great post!
I was very disappointed with the performance of DreamHost. It was too slow, even if only one user (me) was only and only one rails application was installed.
I switched to hostingrails.com and now my rails application is running like a champ. In addition, hostingrails.com supports not only FCGI, but Mongrel as webserver. And pricing is nearly the same like DreamHost.
Thanks to these two articles, my apps have been purring like kittens with mild traffic. Check them out and try them in addition to the tip I mentioned above. Also, be sure to use capistrano for deployment.
James/John, Would you mind sharing any resources you know of for using Capistrano to deploy multiple rails sites on a single DH account?
Thanks,
Sean
Thanks, this helps a lot.
I emailed DH and they confirmed this exact thing, for me (check my page for the short details).