Rails Full Stack Memory Usage, with Graphs!
by Geoffrey Grosenbach
A few months ago I moved my Typo-based blog to a Virtual Private Server. A VPS is a server that is shared with a few other sites. You are guaranteed a certain amount of RAM and have root access to the box. I followed Ezra's instructions and easily installed MySQL, Lighttpd, FastCGI, and Rails. Finally, I removed Apache since I wouldn't be using it.
I didn't do much tuning. MySQL is a basic install and I have one Rails FCGI process and one PHP-FCGI process running (my site stats application runs on PHP). The site gets about 1,500 to 2,000 page views a day, so it's not a high activity site. Still, it has been much more reliable and I have had only one hour of downtime in the last two months when the server rebooted and my reboot script was incorrectly configured.
A few weeks after signing up, I was notified that the hosting company had made a mistake and would be moving my site to a new server. In exchange for the inconvenience, I received a free upgrade from 128MB to 192MB of RAM. The upgrade revealed a few facts about the memory usage of a Rails stack.
|It seems like we're missing a baseline for what your operating system used without the rails stack. Also, it would be interesting to know what the usage per portion of the stack is. Ie.. is all the cpu time spent in the ruby process but all the memory in the database portion, etc.|
|Good point. I used a clean install of Debian but don't have stats on the individual memory requirements of the various pieces. I'll see what I can pull up in relation to that.|
|FastCGI sucks. Its unstable as hell. HTTP proxying is the way to go! You shoul be using Mongrel behind Apache or Lighty instead. MUCH smoother, integrates easily with Capistrano for deployment. 37Signals just switched their deployment over to Mongrel from FastCGI, if I'm not mistaken.|
I agree. I've been using Mongrel for development locally for a while but will be using it in production environments soon.