How much memory do you need to run a Rails app?
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.
NOTE: There are a few spikes in these graphs right before a period of silence. The silence was the switch from one server to another and the spike represents the imaging of the disk from the old to the new (when files were copied over). These graphs are from mid-May when the switch happened.
Swap
The site was fairly responsive to begin with, but there was a small amount of swap. With only 128MB RAM, there were many times that memory needed to be written to disk or read back into memory.

After the switch, swap went down to basically zero. In the months since I notice a small amount of swap activity every few hours.
CPU & Load
The machine was already quite responsive (subjectively), but spent even more time idling on the new server.

It has been suggested that the new server might also have a faster CPU. I don’t have specific data on the machine’s specs.

After a few months, the load is at 0.1 or less, on average, so it’s quite manageable.
Memory
The most interesting graph was memory. The left side shows no free memory and constant swap. The right side shows a little bit of free memory (the dark blue) and average memory usage at about 160 MB.

In the months after these graphs were saved, I have noticed a sawtooth pattern where memory usage will increase for a few hours and then drop down into the 160 MB range. Today’s graph shows some swap, but that’s mostly due to isolated database queries that take extra memory.
One thing I did notice when swiching to a VPS from a shared host is that database performance is much more sensitive on a VPS. You have a fixed amount of RAM for the whole stack. Shared hosts run separate database servers with a lot of memory and your application has access to the whole thing.
Fortunately, a blog can be cached and makes only small queries. I have setup a system where database-intensive queries are run once a day and cached for later use. A few examples are the list of recently popular pages at the bottom of each page and the sparkline graph under each title that shows how many comments have been made per article since the site launched.
Graphs
The graphs are generated by the Munin server monitoring tool.
Learn More!
I’ll be teaching a two day Ruby on Rails Workshop in London on August 10-11! Learn the basics of Ruby on Rails, hands-on. You’ll learn how to develop plugins, program in an agile manner with test-driven development, and produce quality Rails applications. More details here.


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.
These graphs were made a few months ago when lighty was the hottest thing...how quickly the world moves!