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

On 7/4/2025 11:38, Paul wrote:
> 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.

There is a thread on the Github issues page for jemalloc related to 
this, and one mitigation discussed appears to not work (at all) on 
FreeBSD as it is disabled in the build (which I don't quite understand 
the reason for.)

https://github.com/jemalloc/jemalloc/issues/2251

Allegedly jemalloc-5.3 addresses this according to that thread /but 14.3 
appears from the manpage to use 5.2.1 /which, according to the report, 
*_is impacted_* by this.

I can confirm that on 14.3 attempting to set the background reclaim 
thread option in the application or from the environment doesn't do 
anything (and if you do it from the environment it raises a complaint 
that it is not enabled.)

-- 
Karl Denninger
karl@denninger.net
/The Market Ticker/
/[S/MIME encrypted email preferred]/