[JohnBooty]

That's interesting!

I've been doing Ruby since 2014. Mostly Rails, but also a bunch of data processing.

I have run into memory issues at times, when shuffling large amounts of data around. But manually running GC was never the answer in my cases.

In all cases, the memory issues were because I'd created a bunch of heavy objects that were still in-scope and were therefore not eligible to be cleaned up by GC anyway.

This was all Ruby 2.0+ and most of the heavy data processing stuff was 2.3+. So I wasn't doing any of it back in the days of really ancient Ruby GC.

[scruple]

I've done a lot of similar work and learned a lot of similar lessons. They were interesting and fun challenges but I've since moved on from Ruby in my professional life.

I'll say this much: When I was working on these applications, one of the minor wins that I had was swapping them over to the jemalloc memory allocator. It has introspection/instrumentation tooling that is really useful for these sorts of situations. You can use `MALLOC_CONF` [0] to trigger some built-in profiling. For instance, `export MALLOC_CONF='prof_leak:true,lg_prof_sample:0,prof_final:true'` will trigger jemalloc to log the heap at exit which is very useful for tracking down leaks.

[0]: https://github.com/jemalloc/jemalloc/wiki/Use-Case%3A-Leak-C...