Ruby on Rails Memory Efficiency 7

Posted by Christopher Smith Wed, 13 Sep 2006 09:00:00 GMT

Okay, I said I suspected that Ruby wasn’t terribly memory efficient yesterday. Today I have some strong indications that at least Typo isn’t quite so memory efficient.

I had noticed that my blog was getting quite slow and handling updates, and it wasn’t clear to me why. I am particularly sensitive to efficiency issues, because I run this whole thing inside a User Mode Linux instance, which imposes it’s own inefficiencies on pretty much all aspects of the Linux kernel. So I generally have to be fairly careful to tune everything I run inside it to minimize kernel involvement. I was all ready to blame UML again until I looked at what was going on with the instance: it was swapping like crazy.

Some peaking around in the system showed working set sizes for my Ruby FastCGI processes in the 35MB-50MB range (very bad considering my instance only has 64MB of RAM allocated for it) –that’s the kind of footprint that makes you start to think of J2SE/EE! To get an idea of how inefficient that is, Postgres’s working set size for handling this puny blog is about 4-5MB.

So far, I’ve been able to get back to some kind of decent performance by trimming my FastCGI process count down to one (which has some unfortunate side effects, but none as unfortunate as having 20-30MB of memory constantly swapping).

This tweaks my curiosity as to what’s going on under the covers, and how much of the overhead is Ruby, how much is Rails, and how much is Typo.

Trackbacks

Use the following link to trackback from your own site:
http://xblog.xman.org/trackbacks?article_id=ruby-on-rails-memory-efficiency&day=13&month=09&year=2006

Comments

Leave a comment

  1. Rob Sanheim about 9 hours later:

    Are you running Typo 4.0 or up? There were quite a few memory leaks found in 2.6, and in some of the earlier 4 releases that caused the behavior you’re describing.

  2. Christopher Smith about 11 hours later:

    Thanks for the heads up. I’m running Typo 4.0.3. Would you consider the memory footprints I’m describing on the high side?

  3. Vikram. about 15 hours later:

    I am impressed by your command on the efficiency issues. I am not from a computer background but do programming for a living. Can you suggest some books that would give me more information on similar topics.

  4. Darshan 1 day later:

    I had similar problems with FastCGI. Huge memory footprint, database connection losses, etc. I moved over to using Apache as a proxy and mongres as the backend. That totally solved my problem.

  5. Christopher Smith 1 day later:

    That’s bizarre! Why would using Mongrel as a back end save you memory?

  6. Christopher Smith 2 days later:

    Vikram: Sorry, I should have responded earlier but I missed your question. Most of what one needs to know about efficiency can be summed up by: “profile first, optimize second”. ;-) I’m a big fan of tools like OProfile and DTrace for this reason.

    If you really want to get the real nitty gritty on this stuff, you want to read up on compilers and virtual machines. For the former, there is “Advanced Compiler Design and Implementation”. For the latter I find better information in papers. You can find some good papers on the Mono project’s site and some write ups on StrongTalk and Java’s Hotspot VM. What’s nice is that the source code is available for all of those projects if you want to see this stuff in action.

  7. Vikram 2 days later:

    Thanks Chris.

Comments