On Fri, Jun 1, 2012 at 9:07 PM, Jason Evans <[email protected]> wrote: > It's likely that redis is hitting the bug that was fixed for jemalloc 3.0.0 > by this change: > > http://www.canonware.com/cgi-bin/gitweb.cgi?p=jemalloc.git;a=commitdiff;h=4e2e3dd9cf19ed5991938a708a8b50611aa5bbf8 > > jemalloc changed to a finer-grained locking model shortly before the 1.0.0 > release, but the fork-related support didn't have the necessary changes to > lock all relevant mutexes until this change.
Thank you, I'll make sure to upgrade to Jemalloc 3.0.0 for the stable branch of Redis (already done into 2.6 / unstable). I want to say thank you for Jemalloc, it solved our fragmentation problems in an impressive way, basically after the jemalloc adoption we stopped receiving fragmentation reports at all (excluding the false positives about an RSS / sum_of_allocation that was high because the instance was emptied after a peak memory usage. But we can now detect this condition thanks to a new INFO field remembering the peak memory usage). Cheers, Salvatore -- Salvatore 'antirez' Sanfilippo open source developer - VMware http://invece.org Beauty is more important in computing than anywhere else in technology because software is so complicated. Beauty is the ultimate defence against complexity. — David Gelernter _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
