Re: [RFC] Introducing pm.max_memory for PHP-FPM
| From: | Rob Landers | Date: | Thu, 30 Jan 2025 18:11:00 +0000 |
| Subject: | Re: [RFC] Introducing pm.max_memory for PHP-FPM | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-126247@lists.php.net to get a copy of this message | ||
On Thu, Jan 30, 2025, at 17:41, Arkadiy Kulev wrote:
> Hello!
>> This wouldn't really work because FPM does not control the script during execution and
>> would have to check it out after each allocation which is not really viable.
>
> Thanks for the feedback! I agree that monitoring memory usage after each allocation would be
> infeasible. However, my suggestion was actually to check memory usage *only once per request*,
> specifically at request shutdown, when FPM regains control and before assigning another request to
> that worker.
>
> We already have hooks for request startup and request shutdown in FPM. Could we simply insert a
> memory check at the request shutdown stage—where the worker is returning control to the FPM master
> process—before picking up a new request?
>
> Just to be clear, "memory_limit" helps kill runaway scripts mid-request. By contrast,
> the newly proposed pm.max_memory is meant to catch processes with a slow leak across multiple
> requests. We only need to check at the end of each request, which is presumably when the worker
> returns control to FPM.
To be honest, I haven't seen a 'slow' memory leak in a long time -- except when using
fgetcsv which has had a reported memory leak since ~2012 somewhere on the old bug tracker. (I lost
the link to it and don't even remember how to get to the tracker or if it still exists.) I
haven't checked if it has been fixed since 8.2, but I've seen a couple of reports of it on
r/php a couple of times in the last couple of years.
— Rob