Abnormal memory usage with glibc 2.31 related to trimming strategy ?

[Carlos O'Donell]

On 9/22/20 10:09 AM, Xavier Roche via Libc-help wrote:
> Hi,
> 
> On Mon, Sep 21, 2020 at 1:18 PM Xavier Roche <xavier.roche@algolia.com> wrote:
>> Just to add some small details that may be insightful: in the later
>> scenario, with 12 heaps, the total overall rest size was 100376946145
> 
> To be correct, even with GLIBC_TUNABLES=glibc.malloc.arena_max=1, the
> pool (which is the main sbrk() pool, I suppose) grows.
> In the later example, I could count 6806 blocks up to 35326884838 Bytes.

The glibc algorithms are considered "heap based" rather than "page based."
The allocations that are temporally close to each other are close to
each other on the virtual heap (made up of possibly many logical heaps
linked together as an arena).

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.

At some point the algorithm may become stable. At some point you may
have enough chunks in the free lists to satisfy any of the workload requests.
The question is: Where is that stability point? The stability point depends
on the exact workload and the interaction with the algorithm.

Or allocations that last a long time will prevent the "top" of the heap
from freeing down below that point. So you can ratchet up the top
of the heap and keep moving a long lasting allocation forward with the top
of the heap and so prevent any allocations from being freed down below that
point on the virtual heap. If you can't manage those long-lived allocations
then you may need to call malloc_trim() periodically to walk the free lists
and free the coalesced pages rather than relying on the heap to free down.

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

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.

-- 
Cheers,
Carlos.