Memory Leak with rocksdb version 6.6.3 ? about rocksdb

[Robin3910]

I see. We use jemalloc since the RSS with glibc malloc tends to be high for RocksDB-based applications (example: https://smalldatum.blogspot.com/2015/10/myrocks-versus-allocators-glibc.html). if there's actually a memory leak that won't help, but just fyi.

Hi ajkr, thanks for your infomation and help.

I did the tests of glibc and jemalloc, here are some findings from my experiments:
when I use jemalloc the memory increases as well. But after reaching the threshold set by the block cache, it stops increasing. This is different from the performance of glibc's malloc. After glibc reaches the point set by the cache, the memory will still continue to increase, but the extent of the increase will be reduced.

By the way, I use jeprof to draw the call stacks diagram of rocksdb. From the call stack diagram, only one NewDataBlockIterator can be seen, which is inconsistent with the previous iterator assumption of resource occupancy.
The main method of using memory is: rocksdb::AllocateBlock. I'm not sure if this makes sense but it should be certain that the memory increase is not caused by iterators.

[Robin3910]

In the online environment, when there is a lot of reading during peak periods, the memory will always increase, and once it increases, it will not fall back. The more rocksdb reads, the more resources it applies for, and the more memory and swap are consumed, which will not decrease.

My rocksdb size is 200GB. The RSS is 64GB, swap is 32GB.

[Robin3910]

I want to konw rocksdb itself close the iterators or not? I found the memory grow unlimitly and never decrese. I didn't use any iterators in my code and I just use the Get() interface only, so I guess rocksdb use lots of iterators by Get(), and not close it.

see the similar issue: #3216

I want to konw there is any method that I can release the iterator, make memory reclaim

[ajkr]

I want to konw rocksdb itself close the iterators or not? I found the memory grow unlimitly and never decrese. I didn't use any iterators in my code and I just use the Get() interface only, so I guess rocksdb use lots of iterators by Get(), and not close it.
see the similar issue: #3216

I want to konw there is any method that I can release the iterator, make memory reclaim

There is no API to release the iterators you described since they are not known to exist.

Can you build with ASAN enabled, and then run your program for a bounded duration to check for memory leaks?

What allocator do you use? Can you provide a heap profile, and/or allocator stats? If you use jemalloc, the latter can be printed to the LOG file by setting dump_malloc_stats and stats_dump_period_sec.

[Robin3910]

I want to konw rocksdb itself close the iterators or not? I found the memory grow unlimitly and never decrese. I didn't use any iterators in my code and I just use the Get() interface only, so I guess rocksdb use lots of iterators by Get(), and not close it.
see the similar issue: #3216

I want to konw there is any method that I can release the iterator, make memory reclaim

There is no API to release the iterators you described since they are not known to exist.

Can you build with ASAN enabled, and then run your program for a bounded duration to check for memory leaks?

What allocator do you use? Can you provide a heap profile, and/or allocator stats? If you use jemalloc, the latter can be printed to the LOG file by setting dump_malloc_stats and stats_dump_period_sec.

OK, Thanks. I will try it. I currently use glibc as allocator.

[ajkr]

I see. We use jemalloc since the RSS with glibc malloc tends to be high for RocksDB-based applications (example: https://smalldatum.blogspot.com/2015/10/myrocks-versus-allocators-glibc.html). if there's actually a memory leak that won't help, but just fyi.