Default to mimalloc as the memory allocator - provide max_memory config option

[nicolas-grekas]

musl's malloc uses a global lock, which is a serious bottleneck for multi-threaded workloads like FrankenPHP. Under sustained concurrent load, malloc contention can cause threads to stall.

FrankenPHP already supports mimalloc opt-in for static builds (MIMALLOC=1) since #666, but it's off by default.

Enabling mimalloc by default would improve performance and memory behavior, especially on Alpine/musl-based Docker images.

Additionally, mimalloc's per-thread heap stats could enable a max_memory setting (restart a thread when its heap exceeds a threshold), complementing the existing max_requests setting for more targeted leak mitigation (see #2292).

What about enabling mimalloc by default on all builds?

Relates to #481

[henderkes]

#2248

I sniped you with this one - I was against enabling it for glibc (some terrible software, cough, proprietary drivers, cough, loads in ways where mimalloc would break their own assumptions) and Kévin wanted to keep things consistent everywhere, hence we kept using the system allocator everywhere by default.

[nicolas-grekas]

Maybe providing the max_memory option could help us reconsider?

[henderkes]

I think it's a bit of a slippery slope with the static glibc binary. We either link in mimalloc statically, which works but breaks loading shared extensions, or we now need to ship a mimalloc dll and users must set it as LD_PRELOAD or shared extensions/FFI break.

So we'd realistically need to treat the Docker image and system packages differently from the static binary, which is not a good idea. That's why I wanted to only do it for musl, which is where Kévin disagreed with using different allocators between different operating systems.

I also personally don't think a max_memory option is all that useful. The OS manages that pretty well by itself and tuning can be done with num_threads.

[nicolas-grekas]

OK makes sense.
What about a global max_memory setting then?
When reached, we'd restart all PHP threads.
I'm still looking at my not-prod-ready feeling when FrankenPHP stopped replying without anything in the logs.

[henderkes]

Not opposed to such a setting, but I don't think that would really help.

I've had that "FrankenPHP stopped replying" to anything too, once about half a year ago, but my production logs showed FrankenPHP at only 2.9G of memory, so I doubt it was related. I've been hoping it would happen again to get some conclusive logs or a trace at least, but it hasn't. :/

[nicolas-grekas]

Oh, OK, so lets confirm #2292 fixes it for me first (it happened in days)

[henderkes]

Out of curiosity, was it just the session that became unresponsive for you, or all requests? The session thing may have already been fixed in v1.12.X.

[nicolas-grekas]

All the app was down.

[AlliBalliBaba]

#2293 should also fix some fatal crashes by restarting the entire thread if anything goes wrong in an extension.

Having something like max_memory could be interesting for autoscaling though, add new threads until we reach max_memory, then only stop threads.

Never had a single production crash in almost 2 years, but using worker mode which feels very resilient.