Open GoogleCodeExporter opened 8 years ago
Read thru a few discussions and issues and thought more information is needed
for this issue.
Some more information:
On the master for the same data the used_memory_rss is less than 7G
used_memory_rss:70872650752
mem_fragmentation_ratio:1.16
On the slave:
used_memory:5322895096
used_memory_human:4.96G
used_memory_rss:16309473280
mem_fragmentation_ratio:3.06
We had to do SLAVEOF NO ONE and SLAVEOF <HOST> <PORT> about 3 times due to
replication delays on a flaky network.
It would be good to look at this problem as I think it is genuinely a memory
leak v/s "it's just how it works".
Thanks,
Gaurav.
Original comment by gauravk...@gmail.com
on 3 Jun 2011 at 9:37
It is not a memory leak since Redis tracks all allocations, and its view of the
world is that only 4.96G is allocated. Rather, at some point in time it needed
way more memory which caused the allocator to increase the heap size, do a
couple of allocations there, which in turn cause the heap to remain fixed at
that high limit. Instead of using the default allocator, libc malloc, you could
try running Redis configured to use jemalloc to see if this alleviates this
problem. You can find this branch here:
https://github.com/antirez/redis/commits/2.2-jemalloc-static . You can compile
it using "USE_JEMALLOC=yes make". Make sure jemalloc is used by checking the
"mem_allocator" field in the INFO output. There have been reports of jemalloc
greatly reducing the memory fragmention, and it could be a solution for the
problem you're seeing here.
Original comment by pcnoordh...@gmail.com
on 3 Jun 2011 at 9:46
Original issue reported on code.google.com by
gauravk...@gmail.com
on 28 May 2011 at 12:03