3 ms·

I did research into the glibc memory allocator. Turns out this is not memory fragmentation, but per-thread caches that are never freed back to the kernel! A fre

I did research into the glibc memory allocator. Turns out this is not memory fragmentation, but per-thread caches that are never freed back to the kernel! A free() call does not actually free the memory externally unless in exceptional circumstances. The more threads and CPU cores you have, the worse this problem becomes. One easy solution is setting the "magic" environment variable MALLOC_ARENA_MAX=2, which limits the number of caches. Another solution is having the application call malloc_trim() regularly, which purges the caches. But this requires application source changes. https://www.joyfulbikeshedding.com/blog/2019-03-14-what-causes-ruby-memory-bloat.html https://www.joyfulbikeshedding.com/blog/2019-03-14-what-caus...

glandium 2y ago
The glibc memory allocator DOES have pathological cases that lead to what can look like memory leaks. See https://glandium.org/blog/?p=3698 https://glandium.org/blog/?p=3698 https://glandium.org/blog/?p=3723 https://glandium.org/blog/?p=3723 https://sourceware.org/bugzilla/show_bug.cgi?id=23416 https://sourceware.org/bugzilla/show_bug.cgi?id=23416 (despite being rather old, it's also still a problem)
- wengo314 2y ago
  FWIW i had it with icinga2. so now they actually preload jemalloc in the service file to mitigate the issue, this may very well be what you're talking about in case someone is interested: https://github.com/Icinga/icinga2/issues/8737 https://github.com/Icinga/icinga2/issues/8737 (basically using jemalloc was the big fix) https://icinga.com/docs/icinga-2/latest/doc/15-troubleshooting/#try-swapping-out-the-allocator https://icinga.com/docs/icinga-2/latest/doc/15-troubleshooti...