Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126255
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: Fri, 31 Jan 2025 11:26:05 +0100
Message-ID: <CAEKnhAGpzS4eNj4m5=p731CWo6na2r_CYHFQ9T8SWCtOgMENrQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Introducing pm.max_memory for PHP-FPM
To: Rob Landers <rob@bottled.codes>
Cc: Arkadiy Kulev <eth@ethaniel.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000000b07b5062cfdf999"
From: bukka@php.net (Jakub Zelenka)

--0000000000000b07b5062cfdf999
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.
>

I think it might still happen from time to time in external extensions.
Just recently Niels fixed this one
https://github.com/php/pecl-xml-xmldiff/pull/3 . In addition there can be
also a bug in an external library so it's not unlikely that there are still
many such cases.

Currently many people just have pm.max_requests in configuration for that
which is sometimes set to unnecessary low value. Having option that depends
on memory instead could reduce significantly the number of restarts - in
most cases probably to zero. In addition, it could also help to identify
that there is a leak which can get unnoticed if the users don't have alarms
on memory usage or just use pm.max_requests.

Regards

Jakub

--0000000000000b07b5062cfdf999
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"msg-5740760815873755=
155"><br>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></blockquote><div><br></div><div>I think it might still happen from=
 time to time in external extensions. Just recently Niels fixed this one <a=
 href=3D"https://github.com/php/pecl-xml-xmldiff/pull/3">https://github.com=
/php/pecl-xml-xmldiff/pull/3</a> . In addition there can be also a bug in a=
n external library so it&#39;s not unlikely that there are still many such =
cases.</div><div><br></div><div>Currently many people just have pm.max_requ=
ests in configuration for that which is sometimes set to unnecessary low va=
lue. Having option that depends on memory instead could reduce significantl=
y the number of restarts - in most cases probably to zero. In addition, it =
could also help to identify that there is a leak which can get unnoticed if=
 the users don&#39;t have alarms on memory usage or just use pm.max_request=
s.</div><div><br></div><div>Regards</div><div><br></div><div>Jakub</div><di=
v><br></div><div><br></div></div></div>

--0000000000000b07b5062cfdf999--