Abnormal memory usage with glibc 2.31 related to trimming strategy ?

[Xavier Roche]

Hi Carlos!,

On Thu, Sep 24, 2020 at 9:14 PM Carlos O'Donell <carlos@redhat.com> wrote:
> The implication is that you can get ratcheting in memory usage if you have
> a producer consumer model that effectively keeps growing the "top" of the
> heap by somehow avoiding the reuse of the chunks on the free lists.

We do have quite aggressive memory usage for short spans, which might
explain the issue.

Note that after several days, with only one pool, the memory
consumption remains stable at 50GB (for 3GB of memory really used),
which was the peak memory consumed at some point in the process
history.

I tried to look at the glibc allocator history (git log
--format=oneline glibc-2.23..glibc-2.31 -- malloc/malloc.c) but the
code has changed quite a bit between the two versions, so there are
many candidates for this regression.

> What we really need is a good heap dumper to visualize what your heap status
> is and what is consuming space.

Could an adapted version of malloc_trim do the trick ? We "just" need
to dump more details basically (instead of counting blocks, we could
dump start and size). Or maybe playing with some gdb scripting could
do the trick alternatively.

I'd be happy to provide any information if anyone has some suggestions.

> For similar problems we developed a tracer/simulator:
> https://pagure.io/glibc-malloc-trace-utils, but we need the equivalent
> dumper visualizer. The tracer can tell you if your usage is based
> on actual API demand or not.

If it can provide useful information, I can definitely try to produce
a trace. But the amount of logs may be huge (the issue is visible
after ten hours of intensive usage)

Thanks for the useful info!

-- 
Xavier Roche -