Revisiting taming ruby's memory bloat meta-edition

An article, posted about 5 years ago filed in ruby, memory, bloat, consumption, speed & rails.

There are a lot of things that I don’t understand. One of these things is how memory management really works. Memory management is hard, and even though I use languages that do garbage collecting by themselves, long running ruby apps seem to run out of memory after n number of days. Even the pro’s find it quite hard. While I previously resetted the failing app every now and then, I was triggered by Mike Perham’s (creator of Sidekiq) post: “Taming Rails memory bloat”.

Revisiting taming ruby's memory bloat meta-edition

When you start searching for the memory bloat problem, you’ll find several directions. The easiest is changing a global variable which changes the number of “arena’s” where memory allocation takes place (note: I’m in no position to explain all this, please follow the references). The fanciest, however, seems to be changing the memory allocator from glibc’s default ‘malloc’ to jemalloc. See for example this and this article. The reason that jemalloc is popular is that probably that people think that “without reducing arena’s we still get the benefits similar to reducing the arena’s in malloc”. hence, several software engineers requested defaulting the default ruby interpreter to jemalloc instead of malloc. However, it turns out that later versions of jemalloc actually behave quite the similarly to malloc… (see the thread in the ruby issue). Maybe underneath the older version of jemalloc there was a different default arena setting? I don’t know. And actually, I don’t want to know.

Luckily there are also smarter people, like Hongli Lai (co-creator of Passenger), who do understand what they’re talking about. And I’m glad I stopped recompiling my ruby interpreter (even though it sounds harder than it is these days). Turns out the malloc of glibc isn’t so bad after all. Or maybe it is a tad bit worse, but who cares… I prefer good enough defaults over worrying about specific project’s settings, let alone the requirement to create a special build of the ruby interpreter.

The gist of this all: stick to project’s defaults when you don’t really know what you’re doing. Don’t take a random tutorial about recompiling and a few successful experiences for granted. The hard option may often not be the wisest option. And when you want to improve memory now, simply set MALLOC_ARENA_MAX = 2. Apparently it is set to such a much higher value in linux by default because Red Hat’s customers typically prefer it.

Photo by Franck V. on Unsplash

Op de hoogte blijven?

Maandelijks maak ik een selectie artikelen en zorg ik voor wat extra context bij de meer technische stukken. Schrijf je hieronder in:

Mailfrequentie = 1x per maand. Je privacy wordt serieus genomen: de mailinglijst bestaat alleen op onze servers.