That's Not a Memory Leak, It's Bloat

Our Rails customers often run into memory issues. The most frequent cause these days is what we in Support dub ‘bloated mongrels.’

To be fair, bloat has absolutely nothing to do with mongrel itself, which is a solid and fine piece of work. You can run into this problem just as easily with thin, passenger, etc. Changing to a different server will not save you, as the root cause is not the server, but the code the server is running for you.

A real true-blooded memory leak is rare in comparison to the occurrence of bloating Rails instances. If your mongrels (or thins, or passenger instances) are suddenly sporting 100MB or more of extra weight, look no further: we’ve got the diet plan for you!

Bloat is easily identifiable. Last week, your mongrels were at 110MB, but after a new feature or two and a bit of ‘optimization’…. well, lets just say that you’d have trouble fitting one on a CD. It’s not always that dramatic (probably the average size of bloated mongrels are 200-300MB), but basically the mongrels are 2-5x larger than they should be, or spike in size suddenly after a certain subset of requests.

The easiest way to detect bloat is to watch the Application Server process size. New Relic, for example, will show you combined memory usage. You could watch it live with “top” on your slice/server. In both cases, you are looking for quick jumps in process size. If you’re using mongrel, you should be using monit to watch it precisely for this reason. Monit will log to syslog, and assuming that you’ve setup memory limits, you could run something:

Leave a Comment