Abnormal memory usage with glibc 2.31 related to trimming strategy ?

[Xavier Roche]

Hi Konstantin,

On Fri, Sep 18, 2020 at 6:45 PM Konstantin Kharlamov <hi-angel@yandex.ru> wrote:
> `glibc.malloc.tcache_count`: "If set to zero, the per-thread cache is
> effectively disabled."
> So what you can do is to play with this tunable to see if it affects the
> behavior you see.

Thanks for pointing me to this setting I did indeed miss.

Unfortunately it did not improve the situation
(GLIBC_TUNABLES=glibc.malloc.tcache_count=0), as the process started
to slowly grow as usual, now eating more than 50GB of released memory.

Looking at the malloc.c code, it seem that the thread cache can not be
the culprit: blocks are rather small (governed by get_max_fast()
limit)

So this is probably related to another issue; possibly the number of heaps ?

The only workaround for now seems to be to call malloc_trim(0) on a
regular (ie. with a period of 30 seconds) basis. But this is a rather
unfortunate workaround.

Regards,

-- 
Xavier Roche -