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
