PHP fpm pool stirbt leise

[Tim Ritberg]

Hi!

Ich habe hier einen Server mit einigen kleinen Webpressseiten und PHP
7.4 als FPM laufen.

Der Traffic ist niedrig. Denn noch scheint ein Wordpress rechenlastig zu
sein, ich habe es in einen eigenen Pool geschoben.
Da ist mir aufgefallen, dass die Worker/Forks gar nicht ihre maximale
Lebenzeit (500 Requests) erreichen und schon so mit ca. 200 sterben.

Das Log auf notice sagt dazu gar nichts, erst mit debug kommt sowas:
"pm_children_bury(), line 261: [pool $bla] child 8559 has been killed by
the process management after 144.199528 seconds from start"

Der andere Pool loggt normal über notice:
"child $bla exited with code 0 after 10841.346 seconds from start"

Über die Statistic /status kann ich die aufgelaufenen Requests per
Pool/child sehen.

Der process manager läuft als dynamic.

Ideen dazu?

Tim

[Arno Welzel]

Tim Ritberg, 2023-03-16 18:40:

> Ich habe hier einen Server mit einigen kleinen Webpressseiten und PHP
> 7.4 als FPM laufen.

PHP 7.4 ist end-of-life.

Ich würde prüfen, ob man die zumindest auf PHP 8.0 umstellen kann.
WordPress selbst läuft mit PHP 8.0, nur manche AddOns sind vielleicht
noch nicht soweit - aber hier laufen fast alle WordPress-Sites schon mit
PHP 8.0, manche auch schon mit PHP 8.1.

> Der Traffic ist niedrig. Denn noch scheint ein Wordpress rechenlastig zu
> sein, ich habe es in einen eigenen Pool geschoben.
> Da ist mir aufgefallen, dass die Worker/Forks gar nicht ihre maximale
> Lebenzeit (500 Requests) erreichen und schon so mit ca. 200 sterben.
>
> Das Log auf notice sagt dazu gar nichts, erst mit debug kommt sowas:
> "pm_children_bury(), line 261: [pool $bla] child 8559 has been killed by
> the process management after 144.199528 seconds from start"
>
> Der andere Pool loggt normal über notice:
> "child $bla exited with code 0 after 10841.346 seconds from start"
>
> Über die Statistic /status kann ich die aufgelaufenen Requests per
> Pool/child sehen.
>
> Der process manager läuft als dynamic.

dynamic würde ich nur im Ausnahmefall machen, wenn man völlig unsicher
ist, wieviel Last auf dem Server anfällt. static ist oft deutlich
stressfreier. Auch die Anzahl maximaler Requests pro Worker würde ich
deutlich höher setzen, z.B. 5000 oder 10000. Das die Worker überhaupt
beendet werden, ist ja nur eine Sicherheitsmaßnahme um negative
Auswirkungen durch Memory Leaks zu vermeiden.

Hier läuft eine WordPress-Website mit ca. 2000-5000 Visits pro Tag mit
folgenden Einstellungen:

pm = static
pm.max_children = 10
pm.max_requests = 5000

Wobei ich pm.max_requests erstmal auf 0 (unbegrenzt) lassen würde und
dann beobachten würde, ob eine Begrenzung überhaupt notwendig ist und
ggf. mit Apache JMeter o.Ä. testen.


--
Arno Welzel
https://arnowelzel.de

[Tim Ritberg]

Am 17.03.23 um 15:42 schrieb Arno Welzel:

> Tim Ritberg, 2023-03-16 18:40:
>
>> Ich habe hier einen Server mit einigen kleinen Webpressseiten und PHP
>> 7.4 als FPM laufen.
>
> PHP 7.4 ist end-of-life.

Nicht für Debian! ;-)

>
> dynamic würde ich nur im Ausnahmefall machen, wenn man völlig unsicher
> ist, wieviel Last auf dem Server anfällt. static ist oft deutlich
> stressfreier. Auch die Anzahl maximaler Requests pro Worker würde ich
> deutlich höher setzen, z.B. 5000 oder 10000. Das die Worker überhaupt
> beendet werden, ist ja nur eine Sicherheitsmaßnahme um negative
> Auswirkungen durch Memory Leaks zu vermeiden.

Ich hatte die Worker schon höher, aber das bringt ja nichts, diese Zahl
erreicht er nie.

> Hier läuft eine WordPress-Website mit ca. 2000-5000 Visits pro Tag mit
> folgenden Einstellungen:
>
> pm = static

Probiere ich vielleicht mal aus.
Wobei der andere Pool ja super mit dynamic läuft.

Tim