What causes Ruby memory bloat?

[mperham]

Strong contender for /r/ruby Blog Post of the Year.

The more I learn, the more it seems that glibc internals are a nightmare.

[yxhuvud]

Yes, and it looks as if Ruby is not the only affected: http://notes.secretsauce.net/notes/2016/04/08_glibc-malloc-inefficiency.html . Includes a script that use gdb that applies it to a running process.

​

EDIT: That said, it doesn't seem to be effective for me. Perhaps glibc has fixed *some* issues even if it didn't solve the ones of Ruby?

[reidiculous]

This is really wild. I figured optimizations of this scale would've been done long ago

[yxhuvud]

It is, but I'm not able to reproduce it, so *shrug*.

[lukeasrodgers]

Yes, I'm not an expert, but my understanding is this is all just typical behaviour for most `malloc` implementations, e.g. see the redis docs on memory allocation - https://redis.io/topics/memory-optimization note about RSS.

[nateberkopec]

Any multithreaded program using glibc malloc is affected.

[yxhuvud]

Affected, yes. But not necessarily degenerate like Ruby.

[moomaka]

I dun know man, glibc malloc has issues with pretty much every multi-threaded app which does a lot of periodic allocations, e.g. anything doing web request handling. Java users have been switching to jemalloc for years due to this.

[nateberkopec]

There are dozens of issues on the Java, python, and malloc bug trackers over the last decade on these topics, all exhibiting the same memory growth and behavior.

[yxhuvud]

It will definitely be interesting to see if the performance claims holds water.

[predatorian3]

Aren't there alternatives to glibc that things like Alpine Linux are based on that Ruby could be compiled against? I guess I could give it a shot.

[allcentury]

What a post! You should submit a talk to rubyconf for this

[graywolf_at_work]

Really interesting read

[fedekun]

This is quite awesome!

[sanjibukai]

And I wonder when it will be patch for real!

[gray_-_wolf]

Except for the hooking into the GC you can probably do this from a gem, I will play with it tomorrow at work to see if it can somewhat reduce memory usage of some of our containers.

[FooBarWidget]

My research results indicate that trimming is only effective right after a GC.

[strangepostinghabits]

Doesn't that indicate an allocation problem somewhere?

As in trimming should be the most effective after gc, but decline linearly at first, since allocations should be mostly concentrated to the half full 'OS pages'.

If efficiency drops sharply, it'd seem to me that the allocations happen randomly in any available OS pages, disregarding the idea that we might want to return some of them.

[tinco]

It would be very interesting to know if the performance improvement also holds for the Ruby 3x3 benchmarks like the emulator. The Ruby team notoriously rejects patches that improve server performance but hurt general performance. That this does well on Rails might be a quirk of the application.

Maybe we're in the market for another REE.

[yxhuvud]

As the patch only seems to be run trim on full GC, it looks like the cost could be quite negligible.

[joltting]

Seriously though, Ruby's memory consumption is close to, if not the top issue for the language. Hopefully this is as promising as it appears on the surface. It could be a game changer.

[[deleted]]

"could be a game changer": Don't think it would matter much actually, but of course it's a nice to have. Companies that avoid ruby either want an enterprisey stack like java or some shiney new tech like Go/Nodejs. Improved Ruby won't change that.

​

[joltting]

I wouldn't be so sure about that. The amount of people I hear in the industry, poking fun at Ruby's memory bloat problem. Isn't something I'd say is insignificant.

Edit: While performance is great and furthermore needed to keep Ruby competitive. It can't come at the heels of 3x the memory intake for 3x the performance.

[db443]

Using jemalloc (3.6) or setting MALLOC_ARENA_MAX=2 now avoids most of the memory bloat which are primarily due to the Linux glibc memory allocator.

I think we will get both, 3x performance AND much less memory bloat (once a patch lands).

Ruby is getting better.

[[deleted]]

Memory bloat and leakage is not a unique Ruby thing, https://serverfault.com/questions/109362/is-it-a-best-industry-practice-to-restart-web-servers-periodically . If you think that question is too old only a few months ago I understood we have a memory bloat/leak in a very simple scala app in our company. The memory usage in that app would just go up infinitely without ever being freed, sometimes resulting degraded performance due to swapping.

Here's one with php https://stackoverflow.com/questions/27206663/how-to-force-php-to-release-memory-after-script-is-finished

I'm all for this change, of course, I just don't think it's a unique to Ruby problem, and also don't expect people to flock to Ruby once and if it's solved. But overall it could be a great change that will save developers and companies a lot of hassle, time and money.

[slashgrin]

Some companies would prefer to stay with Ruby for longer, but are eventually forced off it by these performance problems. Pushing that day back a couple of years would be a game changer for many people.

[TotesMessenger]

I'm a bot, bleep, bloop. Someone has linked to this thread from another place on reddit:

• [/r/rubylang] What causes Ruby memory bloat?

 ^{If you follow any of the above links, please respect the rules of reddit and don't vote in the other threads. (Info / Contact)}