I’m having trouble with Typo growing roughly linearly with the number of
requests, even if the requests are all for the index page. The first
hit results in slightly more growth (~11MB) which is understandable.
after that each request increases memory usage by ~2MB, all the way up
Here’s a graph of memory usage over number of requests:
(The numbers that went into this graph are below.)
So far, the only tool I have to mitigate this unbounded memory growth is
the PassengerMaxRequests directive.
I see some emails from a long while back about this, but they refer to
blog posts that are no longer available:
- Steve L.:
- Paul R Brown:
I tried some profiling with memprof. I noticed that several more
ActiveRecord::Relation objects are hanging around after each request.
Each request leaks two more relations for the Article model, for
But I haven’t been able to find what’s holding references to those on
heap. Perhaps I’m doing something wrong: First of all, my runtime
object_ids don’t match what memprof dumps in JSON, and second of all,
walking memprof’s JSON heap dump from globals indicates that these
relations are not actually reachable. As I understand, MRI 1.8.7’s
mark-and-sweep GC should free anything that’s unreachable. Not sure why
that doesn’t add up. Here’s how I’m walking the heap:
Has anyone else:
(a) seen this behavior of memory growth?
(b) figured out how to keep the memory footprint bounded?
When I compare to something like Enki blog, I see that after about two
requests, the memory usage remains constant no matter how many requests
make, so it’s not an issue that applies to all Rails apps. (But Typo
so many more features than Enki that I would not want to have to
Data from graph linked above (# requests vs. KB RSS Memory):