Am limitat PHP-FPM la 40 de copii și consumul de memorie a scăzut

Acum două săptămâni, pe un VPS cu 4 GB RAM și PHP 8.2, un endpoint de raportare genera fișiere CSV de aproximativ 80 MB. Totul rula pe PHP-FPM cu pm = dynamic și pm.max_children = 120. La 30–40 de cereri simultane, memoria ajungea la 3,7 GB, iar OOM killer-ul oprea procese fără nicio linie în php_errors.log.

Am început prin a măsura, nu prin a ghici. Am adăugat în www.conf:

pm.status_path = /status
slowlog = /var/log/php-fpm/slow.log
request_slowlog_timeout = 5s

Apoi am citit pm.status?full sub load. Media per proces era de 45–60 MB, dar vârful la cererile CSV urca la 180 MB. Cu 120 de copii, matematic nu încăpea. Am redus la 40 și am pus pm.max_requests = 500 ca să recicleze procesele care acumulau memorie.

pm = dynamic
pm.max_children = 40
pm.start_servers = 8
pm.min_spare_servers = 4
pm.max_spare_servers = 12
pm.max_requests = 500

Diferența a fost imediată: memoria a stat sub 2,6 GB, iar timpii p95 au scăzut de la 4,1 s la 2,3 s, pentru că procesele nu mai schimbau constant. Am mutat generarea CSV-ului într-un job separat, cu fputcsv pe stream, nu cu array în memorie.

Mecanismul e simplu: fiecare copil PHP-FPM are propriul spațiu de memorie, iar pm.max_children nu e o sugestie. Dacă îl lași mare, kernelul decide pentru tine. Costul e că cererile stau în coadă la vârf; la 40 de copii, am văzut cozi de 1–2 secunde la 60 req/s. Am acceptat asta pentru că endpointul greu era oricum asincron.

Unde se strică: dacă ai extensii care alocă mult per request (imagick, anumite drivere de bază de date), media per proces crește și calculezi greșit. Am pățit-o cu o extensie de PDF care adăuga 90 MB la primul request. De asemenea, pm.max_requests prea mic (100) producea un val de fork-uri la fiecare câteva minute. Și pm.status_path expus public e o scurgere de informații; l-am legat doar la 127.0.0.1.

Voi cum vă dimensionați pm.max_children? Vă uitați la memoria medie sau la vârful per request?