Hi!
> 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. >> > >> > I think that would require a different name because it would not reflect > max memory usage in any way - it would be measured at the time when the > memory usage is lowest. We could maybe set some options that would measure > the maximum of increase of memory between requests - I mean difference > between lowest memory usage (most likely after the first request) and then > compare against current usage after the latest request and set limit on > this difference. Not sure about the name for that. Maybe something like > pm.max_memory_increase or something like that. > I see where you’re coming from, but I believe measuring memory “delta” or “increase” could be confusing for end users. In practice, admins and developers often glance at tools like top or ps to see *current* memory usage for each FPM worker, spot outliers, and then set a threshold accordingly. If we start talking about “lowest usage” vs. “current usage” and a “max increase,” that becomes much harder to translate to real-world monitoring—and it’s non-intuitive compared to simply reading the value right off top and setting a limit. So, from a usability standpoint, I think a direct measurement of resident memory (as people see in common system tools) would be the most straightforward and least confusing. > 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. >> > > There is one thing to note that memory_limit actually measure only memory > allocated through the per request php memory allocator so it's not actually > limit on total usage including the standard allocator memory usage. So > there would be still a use case for total limit using cgroups but I agree > that the more important use is to catch slow leaks which the above should > help with in a better way than pm.max_requests. > You’re absolutely right that cgroups handle total memory usage—including memory outside the PHP allocator—more accurately. But as I’ve mentioned before, relying on cgroups to limit memory typically means an OOM kill that can happen at *any* moment, often right in the middle of a request. That’s precisely what I’m trying to avoid. The whole idea behind pm.max_memory is to allow a *graceful* check *after* each request completes, so we can recycle the worker before starting a new request. That way, no request gets abruptly killed. cgroups don’t really accommodate that scenario—they’re great for overall resource control but not for per-request, child-level recycling within FPM.
