Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126244
Precedence: bulk
MIME-Version: 1.0
References: <CAGVaEcmDxxbFzNxXnF=jmdUDnQTk55zgorbsqQqyP8w2Z=-iaw@mail.gmail.com>
 <CAEKnhAFeiJESkqJ0o9PuU59VFK1hdfk2xeEDJn_BbsaF0sBy7Q@mail.gmail.com>
In-Reply-To: <CAEKnhAFeiJESkqJ0o9PuU59VFK1hdfk2xeEDJn_BbsaF0sBy7Q@mail.gmail.com>
Date: Thu, 30 Jan 2025 10:41:53 -0600
Message-ID: <CAGVaEcnOWGYPPUTYn1OZkxCvLmXSnzrQm73YB=ucRMuOA6DCpA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Introducing pm.max_memory for PHP-FPM
To: Jakub Zelenka <bukka@php.net>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000b9349062cef1c47"
From: eth@ethaniel.com (Arkadiy Kulev)

--0000000000000b9349062cef1c47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 n=
ot
> 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=E2=80=
=94where
the worker is returning control to the FPM master process=E2=80=94before pi=
cking 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.

--0000000000000b9349062cef1c47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hello!<br><br></div></div><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>This wouldn&=
#39;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 vi=
able.</div></div></div></blockquote><div><br><div>Thanks for the feedback! =
I agree that monitoring memory usage after each allocation would be infeasi=
ble. However, my suggestion was actually to check memory usage <b>only once=
 per request</b>, specifically at request shutdown, when FPM regains contro=
l and before assigning another request to that worker.=C2=A0</div></div><di=
v><br></div><div>We already have hooks for request startup and request shut=
down in FPM. Could we simply insert a memory check at the request shutdown =
stage=E2=80=94where the worker is returning control to the FPM master proce=
ss=E2=80=94before picking up a new request?<br></div><div><br></div><div>Ju=
st to be clear, &quot;memory_limit&quot; helps kill runaway scripts mid-req=
uest. By contrast, the newly proposed pm.max_memory is meant to catch proce=
sses with a slow leak across multiple requests. We only need to check at th=
e end of each request, which is presumably when the worker returns control =
to FPM.</div></div></div>

--0000000000000b9349062cef1c47--