We’re running into memory problems with our rails app.
The short version of the story is that we have a controller than
manipulates a fairly hefty dataset (pulled out of our database).
Whichever fastcgi/mongrel handles that request loads into memory this
The problem is that once the controller has finished running there does
not appear to be any decrease in the memory footprint of the mongrels.
After the user has been working at this for a short while, most of the
mongrels will have serviced such a request and so each one of these is
carting around ~100 megs of RAM (as given by the ‘resident’ column in
top) instead of the usual ~30 or so, which eventually causes our server
to start swapping like mad.
It doesn’t look like straightforward leak: eventually the memory usage
of each mongrel will top out (it usually takes 2-3 or more requests to
I’ve narrowed down the problem somewhat, and as a test I have an action
which looks like this (and which has the same behaviour as the real
actions in the application
c = ActiveRecord::Base.connection
SELECT question_group_entries.* FROM question_group_entries
RIGHT JOIN question_group_user_cache_entries
ON question_group_user_cache_entries.outgoing_message_id =
The details of the query are not important, the significant thing (I
think) is that the the result set is relatively large (~100000 rows
consisting of 3 numbers)
I’ve been poking around with Stephan Kaes’ railsbench, and the GC
related stuff in particular (I have recompiled my ruby interpreter with
the patch he supplies), but I’m not sure what to make of the numbers I’m
getting, or how I should best tweak the GC parameters the patch offers.
In case it matters we’re using MySQL 4.1.12 under Linux on our
production machines (using Apache 1.3 + fastcgi on our production
machine and Apache 2 + 8 mongrels on our test production machine), and
I’m running MySQL 4.1.21 under OS X on my development machine.
Any suggestions as to what we should be looking at would be greatly