On 5/1/19 12:59 AM, Igor Podlesny wrote:
On Tue, 30 Apr 2019 at 20:56, Igor Podlesny <ceph-user@xxxxxxxx> wrote:
On Tue, 30 Apr 2019 at 19:10, Denny Fuchs <linuxmail@xxxxxxxx> wrote:
[..]
Any suggestions ?
-- Try different allocator.
Ah, BTW, except memory allocator there's another option: recently
backported bitmap allocator.
Igor Fedotov wrote about it's expected to have lesser memory footprint
with time:
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2019-April/034299.html
Also I'm not sure though if it's okay to switch existent OSDs "on-fly"
-- changing config and restarting OSDs.
Igor (Fedotov), can you please elaborate on this matter?
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.
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
Mark
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
