Created attachment 7406[details]
example output of --leak-report
The memory usage of the drepl and rpc server processes increases over time, maybe indicating memory leaks. Output of --leak-report is attached. Is there any other useful information to extract to help tracking this down?

Created attachment 7552[details]
leak report with two of the processes owning 1.5GB of memory (rpc_server and drepl?)
As I understand this might be caused by long running memory contexts? The full leak report does not reveal any insight to me yet. Is there any other information that could be useful to narrow this down?

Tests with Metzes malloc-reclaim.c example code show that adjustment of the malloc TRIM and/or MMAP thresholds does not reduce the problem.
shell# gcc -o malloc-reclaim malloc-reclaim.c
shell# MALLOC_TRIM_THRESHOLD_=1 MALLOC_MMAP_THRESHOLD_=1 ./malloc-reclaim
On the contrary, while using using MMAP more or less exclusively makes free() actually return the freed memory immediately, malloc allocates memory pages only in 4k granularity, which isn't efficient in the first place and results in a much larger memory footprint.
Fixing only the TRIM threshold might help in some cases, but not for the specific example of the malloc-reclaim.c example code, because this is explicetely designed to create a large and lasting hole in the heap, while TRIM only acts on unused chunks on the top of the heap. So I guess unfortunately Tridge might be right, advising to reorder the allocation strategy. In this case drepl and rpc_server would need some scrutiny.