[byroot]

> Ruby processes don't return the memory to the system

That is not correct. Ruby do unmap pages when it has too many free pages, and it obviously call `free` on memory it allocated once it doesn't use it.

What happens sometime though is that because of fragmentation you have many free slots but no free whole pages. That is one of the reason why GC compaction was implemented, but it's not enabled by default.

But in most case I've seen, the memory bloat of Ruby applications was caused by glibc malloc, and the solution was either to set MALLOC_ARENA_MAX or to switch to jemalloc.

[jacobsenscott]

I'm correct in practice. There are scenarios where ruby might free memory, but ruby is mostly used for rails, and you won't ever see that under a standard rails workload. It will plataue and stay there until a restart. When people see this they think it's a "bug" or a "leak" but it isn't.

On the last fairly large rails app I tried to use jemalloc on there was no change in memory usage. I believe that advice is a bit outdated. Also note using jemalloc doesn't cause memory to be freed to the system. It reduces fragmentation, at the cost of cpu cycles. There's no free lunch.

[byroot]

> It will plataue

Yes, because extra empty pages are released at the end of major GC, which is occasional, and most web application will cyclicaly use enough memory that they will stabilize / plateau at one point.

> I believe that advice is a bit outdated.

It absolutely isn't, your anecdote doesn't mean much compared to the countless reports you can find out there.

> Also note using jemalloc doesn't cause memory to be freed to the system.

Yes it does, it has a decay mecanism, most allocators do. https://jemalloc.net/jemalloc.3.html

> It reduces fragmentation

Yes, and that allows it to have more free pages that it can release.

> at the cost of cpu cycles

Compared to glibc, not so much.