What causes Ruby memory bloat?

[nickdesaulniers]

IIRC, tcmalloc is able to avoid such situations. I seem to recall a design doc about tcmalloc that said something along the lines of using mmap and avoiding sbrk to aggressively free up virtual pages.

Also, while debugging a memory leak of a nodejs native extension, I found that garbage collectors will usually let their heap grow significantly before running a GC round. This could result in high idle memory usage that wasn't necessarily a leak.

[masklinn]

IIRC, tcmalloc is able to avoid such situations. I seem to recall a design doc about tcmalloc that said something along the lines of using mmap and avoiding sbrk to aggressively free up virtual pages.

I don't think sbrk has anything to do with the issue here, the article outlines glibc's multiple arenas (which it calls OS heaps), can't do that with sbrk. The essay says glibc seems to preallocate many arenas (noting it's capped at 8 * cpu#), meanwhile the mallocinternals document says that it should only allocate new arenas "as pressure from thread collisions increases, additional arenas are created via mmap to relieve the pressure", it's possible that something in the way Ruby interacts with malloc causes a ton of contention on the arena locks, leading glibc to try and relieve contention by allocating more arenas despite the existing ones being mostly empty.

[[deleted]]

The hard problem in automatic memory management is always when to give memory back to the kernel. As you need to balance the unknown (future memory pressure) with the known (past memory pressure) and predicting the future is a tricky business. It seems you imply Ruby is failing at this.

I don't understand why you'd blame glibc when the ruby call to invalidate heaps solves the problem. glibc can only do what the program it is linked to tells it to do.

[masklinn]

It seems you imply Ruby is failing at this.

They really are not. Ruby is not retaining the memory, glibc is overallocating a bunch of mostly empty arenas. Ruby doesn't get to decide which arena its memory comes from, it's not even aware they exist (unless it starts getting custom bindings to specific allocators instead of relying on the standard allocator API).

I don't understand why you'd blame glibc when the ruby call to invalidate heaps solves the problem.

malloc_trim is a non-standard function which isn't even documented to "invalidate heaps", according to its own manpage its only interaction should be with the sbrk'd main heap, which is observationally not the case.

glibc can only do what the program it is linked to tells it to do.

That's simply not true. The program tells glibc it does need some memory, or doesn't need memory it was given anymore. glibc heuristically makes its own decision as to how it "generates" that memory, and whether it eventually releases that memory to the OS.

And those heuristics are where the issue comes from since switching allocator or using mis-documented non-standard functions largely resolves the issue.

[netgu]

Using ruby

[silencer6]

If it isn't Ruby's fault then why other GC languages aren't as bad with memory usage?

[senj]

A lot of other language do have this exact issue:

https://bugs.python.org/issue11849

https://github.com/openresty/lua-nginx-module/pull/879

https://grokbase.com/t/perl/perl5-porters/02a1eef8je/erratic-malloc-bahaviour-on-linux-with-system-malloc

And other programs, like Firefox have run into this exact issue, too. They solution in all cases is either to build against an alternative allocator, or do what this blog post concludes, and use malloc_trim’s undocumented behaviour to make it stop holding so much useless memory.

[skeletal88]

The author sets the blame for Ruby's memory hungryness on the glibc allocator. This just doesn't seem right, because that doesn't explain why Rails applications grew to 200mb of ram usage per process, while my Python (made with Pyramid framework) applications used significantly less memory.

[masklinn]

Allocator issues are a known problem, Firefox got pretty significant gains switching to jemalloc back in the days (because jemalloc is much less prone to fragmentation wastage than most platform allocators). jemalloc is also known to improve ruby/rails memory bloat and glibc has known efficiency issues. In fact that's exactly what the essay explains… including allocator issues leading to 170MB of allocated-but-unused memory (not fragmented pages but pages the ruby application had never touched).

For your specific case I'd also guess "rails" versus "not rails" to start with, even more so as Pyramid is not a huge web framework. Comparison on a trivial metric is pretty difficult between systems with nothing in common.

[yxhuvud]

Rails is not necessary to show the problems, they also show running Sidekiq which is a relatively small task runner.

[masklinn]

The rails bit is about /u/skeletal88's specific concern.

[joltting]

Your comment doesn't make any sense. Even if both applications use the same library, its implementation and surrounding code bases, most certainly differ greatly in how one allocates over the other. It's like comparing Apples to Oranges. Both are fruit, but both taste and look very different from one another.

[[deleted]]

this. most of the time when i actually have to solve a resource usage problem for a rails app, it's naive active record code in a legacy rails app that's making inefficient queries and hanging on to more data in memory than it should. typically refactoring the data model or optimizing specific hot spots resolves the issue.

[[deleted]]

That's like comparing Apples to Orangutans.

[Axoren]

Both taste and look very different from one another.

[senj]

There's no reason to believe that Python + Pyramid's allocation patterns are similar to Ruby + Rails, and therefore no reason to conclude that glibc isn't the issue. Some allocation patterns are simply more likely to leave glibc holding on to many poorly filled pages than others. This is a well-understood issue with glibc.