Memory Fragmentation and Bloat in Ruby
summary
Explains why Ruby processes hold peak memory (bloat) and slowly grow (fragmentation), names the allocator and per-thread arenas as culprits, and gives concrete diagnostics and fixes: compute fragmentation with GC.stat live slots percentage (live slots ÷ eden slots), experiment with the environment variable malloc_arena_max to cap per-thread arenas, switch to jemalloc via LD_PRELOAD to cut fragmentation, avoid large in-memory collections and map that double memory, and shows a Sidekiq case where reducing arenas halves RSS from ~1GB to ~512MB.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:03Why memory matters in Ruby
- 4:21Understanding memory bloat
- 8:54How malloc affects memory
- 13:50Ruby's memory safety philosophy
- 14:32What is memory fragmentation
- 18:03Fragmentation vs memory leaks
- 20:14Measuring fragmentation with GC.stat
- 27:01Fragmentation in Ruby's heap
- 28:28Per-thread memory arenas issue
- 33:08Tuning malloc arena max
- 35:36Solutions to reduce fragmentation
- 37:22Alternative allocators like jemalloc
- 38:28Q&A
related talks
46mHalve Your Memory Usage With These 12 Weird Tricks
19mReworking Memory Management in CRuby: A Practitioner Report
21mOn Memory
33mRails and the Ruby Garbage Collector: How to Speed Up Your Rails App
28mA pragmatic and simple approach to fixing a memory leak
39mThe Life-Changing Magic of Tidying Active...
33m"It is correct, but is it fast?"
30mScaling Rails with JRuby in 2022