Re: [RFC] Introducing pm.max_memory for PHP-FPM

From: 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

« previous php.internals (#126247) next »