On 5/2/19 11:46 AM, Igor Podlesny wrote:
On Thu, 2 May 2019 at 05:02, Mark Nelson <mnelson@xxxxxxxxxx> wrote:
[...]
FWIW, if you still have an OSD up with tcmalloc, it's probably worth
looking at the heap stats to see how much memory tcmalloc thinks it's
allocated vs how much RSS memory is being used by the process. It's
quite possible that there is memory that has been unmapped but that the
kernel can't (or has decided not yet to) reclaim.
Transparent huge pages can potentially have an effect here both with tcmalloc and with
jemalloc so it's not certain that switching the allocator will fix it entirely.
Most likely wrong. -- Default kernel's settings in regards of THP are "madvise".
None of tcmalloc or jemalloc would madvise() to make it happen.
With fresh enough jemalloc you could have it, but it needs special
malloc.conf'ing.
From one of our centos nodes with no special actions taken to change
THP settings (though it's possible it was inherited from something else):
$ cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
And regarding madvise and alternate memory allocators:
https://blog.digitalocean.com/transparent-huge-pages-and-alternative-memory-allocators/
https://www.nuodb.com/techblog/linux-transparent-huge-pages-jemalloc-and-nuodb
https://github.com/gperftools/gperftools/issues/1073
https://github.com/jemalloc/jemalloc/issues/1243
https://github.com/jemalloc/jemalloc/issues/1128
First I would just get the heap stats and then after that I would be
very curious if disabling transparent huge pages helps. Alternately,
it's always possible it's a memory leak. :D
RedHat can do better (hopefully). ;-P
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
