Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126248
Precedence: bulk
MIME-Version: 1.0
References: <CAGVaEcmDxxbFzNxXnF=jmdUDnQTk55zgorbsqQqyP8w2Z=-iaw@mail.gmail.com>
 <CAEKnhAFeiJESkqJ0o9PuU59VFK1hdfk2xeEDJn_BbsaF0sBy7Q@mail.gmail.com>
 <CAGVaEcnOWGYPPUTYn1OZkxCvLmXSnzrQm73YB=ucRMuOA6DCpA@mail.gmail.com> <3624b46b-16f2-4eb3-b1ac-d0439cd79153@app.fastmail.com>
In-Reply-To: <3624b46b-16f2-4eb3-b1ac-d0439cd79153@app.fastmail.com>
Date: Thu, 30 Jan 2025 12:16:35 -0600
Message-ID: <CAGVaEcmaBgWkuZ1gHTtqXJ1S2gvNC2=r8RbfyMsnFYBfOv361g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Introducing pm.max_memory for PHP-FPM
To: Rob Landers <rob@bottled.codes>
Cc: Jakub Zelenka <bukka@php.net>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000d8381062cf06fe1"
From: eth@ethaniel.com (Arkadiy Kulev)

--0000000000000d8381062cf06fe1
Content-Type: text/plain; charset="UTF-8"

>
> 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.
>

A significant number of production environments still run PHP 7.4. Also,
beyond the standard extensions, many installations rely on third-party or
custom C extensions for specialized tasks (e.g., image processing, machine
learning, or connections to external systems). Even a small bug in those C
bindings can cause slow leaks that accumulate over multiple requests. In
these cases, a process-level memory limit (checked after each request) can
help avoid excessive memory growth without waiting on a fix or implementing
a complicated workaround. Though it might be rare in core PHP these days,
the fact that such issues can arise (especially in non-core extensions) is
one of the main reasons some users might like a pm.max_memory mechanism.

--0000000000000d8381062cf06fe1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><div class=3D"msg48623261110971696=
33"><div>To be honest, I haven&#39;t seen a &#39;slow&#39; memory leak in a=
 long time -- except when using fgetcsv which has had a reported memory lea=
k since ~2012 somewhere on the old bug tracker. (I lost the link to it and =
don&#39;t even remember how to get to the tracker or if it still exists.) I=
 haven&#39;t checked if it has been fixed since 8.2, but I&#39;ve seen a co=
uple of reports of it on r/php a couple of times in the last couple of year=
s.</div></div></blockquote><div><br></div><div>A significant number of prod=
uction environments still run PHP 7.4. Also, beyond the standard extensions=
, many installations rely on third-party or custom C extensions for special=
ized tasks (e.g., image processing, machine learning, or connections to ext=
ernal systems). Even a small bug in those C bindings can cause slow leaks t=
hat accumulate over multiple requests. In these cases, a process-level memo=
ry limit (checked after each request) can help avoid excessive memory growt=
h without waiting on a fix or implementing a complicated workaround. Though=
 it might be rare in core PHP these days, the fact that such issues can ari=
se (especially in non-core extensions) is one of the main reasons some user=
s might like a pm.max_memory mechanism.<br><br></div></div></div>

--0000000000000d8381062cf06fe1--