How I dove into a spooky memory leak, found it, but discovered that the actual leak was more on mimalloc's side than on meilisearch's. I used jemalloc's powerful tooling and a bit of help from an LLM to dive into this hard-to-tackle issue.

Lobsters is a community-driven platform for sharing and discussing links to articles, tutorials, and projects related to technology and programming. Readers can learn about a wide range of topics, from software development and system administration to cybersecurity and artificial intelligence. With user submissions, comments, and voting, Lobsters provides a platform for collaborative learning and knowledge sharing among technology enthusiasts.

Lobsters

A deep dive into a memory leak investigation in Meilisearch, tracing through multiple suspects: a bumpalo allocator misuse (storing std::Vec inside bumpalo::Vec, preventing drop glue from running), and ultimately a more significant issue with mimalloc v2 failing to cooperate with LMDB's system allocator. The root cause was that LMDB and Meilisearch were using different allocators, causing pages to be allocated and deallocated without being reusable. Switching to a unified allocator (jemalloc or mimalloc v3) resolved the RSS growth. Mimalloc v3 proved especially effective due to improved thread memory sharing and lower memory usage for large workloads, yielding ~13% performance gains in benchmarks.

The Good, the Bad, and the Leaky: jemalloc, bumpalo, and mimalloc in meilisearch