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.
But
after that each request increases memory usage by ~2MB, all the way up
to
100 requests.

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
example.
But I haven’t been able to find what’s holding references to those on
the
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:

(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
I
make, so it’s not an issue that applies to all Rails apps. (But Typo
has
so many more features than Enki that I would not want to have to
re-implement.)

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. But after that each
request increases memory usage by ~2MB, all the way up to 100 requests.