Re[2]: Weird change of behavior of VSZ allocation in 14.2 compared to 12.4

> 
> On 7/4/2025 09:21, Paul wrote: 
> > 
> > Hi,
> > 
> > Reporting back to share our findings. Unfortunately, it *was* a lucky coincidence. Even with 'unused time' threshold eviction of 5min we observe the same unlimited growth of VSZ, since yesterday's restart we're already at 3:1 ratio of VSZ to RSS:
> > 
> > 
> > 22227 0x801c484f000 0x801c4851000 rw- 2 3 2 0 ----- sw 0.0078125 0.0078125
> > 22227 0x1f7ed1400000 0x1f7ed15e0000 rw- 440 440 1 0 ----- sw 1.875 1.71875
> > 22227 0x1f7ed1600000 0x1f7ed59e7000 rw- 14665 14665 1 0 --S-- sw 67.9023 57.2852
> > 22227 0x1f7ed5a00000 0x1f7ee5f42000 rw- 63610 63610 1 0 ----- sw 261.258 248.477
> > 22227 0x1f7ee6000000 0x1f873b200000 rw- 3021161 3021161 1 0 --S-- sw 34130 11801.4
> > 22227 0x7ffffffff000 0x800000000000 --- 0 0 0 0 ----- gd 0.00390625 0
> > 
> > As before, there's one huge slab that isn't getting defragmented. Allocated memory is mostly constantly recycled and there aren't many allocations that are kept for a long time. Especially overnight. This is also confirmed by the picture seen on 12.4-STABLE. So we can't understand what prevents defragmentation from happening. This VSZ growth is also typical in other processes: the longer they run (or more likely the more allocations they make during their lifetime) the larger VSZ gets.
> > 
> What, if anything, do you have in either /etc/malloc.conf or in the const char* "malloc_conf" as a global in main()?


Hi Karl,

Nope, we never ever tuned the allocator. So there is no `/etc/malloc.conf` file and no use of  `malloc_conf` in any of our applications.
Everything is default on 14.2 as well as on 12.4.