Memory bloat is a real problem, even for mid-size Rails apps.
But it might not be in their interest, if customers are suddenly able to downgrade to cheaper Dynos with less memory, so we‘ll see.
> Memory bloat is a real problem, even for mid-size Rails apps.
Yes, but the solution isn't releasing the memory back to the OS, that's just papering over the cracks. If you're running (say) 10 Rails processes on a machine with 10 GB RAM, and particular request paths/background jobs whatever pushes the process size to 2 GB RAM size, you can release the memory back to the OS after you're done, but you still have the underlying problem which is the process gets to that size in the first place, and if all the processes hit 2GB at once, now you're 10 GB in debt, either in swap, or OOM errors.
The solution you should be looking for is installing something like Scout (or NewRelic, but IMO Scout is better for memory stuff), looking to see what is bloating the processes, and in 99% of the time fixing it using some the Rails' batch find methods (seriously, it's ActiveRecord objects 99% of the time, bonus points for in-memory CSV reading or write buffers).
Rails applications don't have to balloon in memory.
Fullstaq Ruby author here. I have done research on the memory bloat problem[1], and this statement is not true. With the way memory allocation in glibc's ptmalloc2 works, multithreaded processes can reach bloaty proportions even if they don't do much work. I started investigating this whole issue because I had a trivial Ruby HTTP proxy server: it had no reason to use 1.3 GB of memory, it doesn't do anything besides forwarding small requests. That's when I found that ~1 GB of that 1.3 GB of memory wasn't even due to anything that my app did by itself, but it's just how the memory allocator works.
[1] https://www.joyfulbikeshedding.com/blog/2019-03-14-what-caus...
Can you share the method you are using to do it? Not challenging, actually answering. Googling I'm not sure which thing I'm finding is the trivial one you use/recommend.