Abnormal memory usage with glibc 2.31 related to trimming strategy ?

[Konstantin Kharlamov]

On Sat, 2020-09-19 at 16:00 +0200, Xavier Roche via Libc-help wrote:
> 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,
> 

Either way, this looks like a situation that deserves its own page on bugzilla :) So please report a bug about that.