Un site e-commerce plante chaque lundi matin. L''équipe monte le plan VPS. Le lundi suivant, même symptôme : pages blanches, Nginx renvoie 502 Bad Gateway. Le vrai problème n''était pas le CPU — c''est PHP-FPM qui avait épuisé ses workers et la RAM en même temps. Régler FPM, c''est équilibrer capacité de réponse et plafond mémoire. Mal calibré, le serveur devient un pari : soit les visiteurs attendent, soit le kernel tue des process.
PHP-FPM gère un pool de processus PHP. Chaque requête dynamique consomme un worker. Si les 20 workers sont occupés, la 21e requête attend dans une file — le TTFB explose. Si vous en lancez 200 sur 4 Go de RAM, l''OOM killer intervient.
Lire l''état actuel avant de toucher quoi que ce soit
Avant tout pm.max_children = 50 copié depuis un forum :
# Processus FPM et RAM (exemple pool www)
ps --no-headers -o rss,cmd -C php-fpm8.2 | awk '{sum+=$1} END {print sum/1024 " Mo total"}'
Repérez aussi :
listen.queuedansphp-fpm status— requêtes en attente.- 502/504 corrélés aux pics dans les logs Nginx.
slowlog— scripts qui retiennent les workers longtemps.
| Signal | Interprétation |
|---|---|
| Queue > 0 régulière | Pas assez de workers ou scripts trop lents |
| RAM swap utilisée | Trop de workers ou fuite mémoire PHP |
| Workers idle = max en permanence | Pool sous-dimensionné |
| Workers idle = 0, RAM OK | Scripts lents, pas pool trop petit |
Calculer pm.max_children sans formule magique
La formule de base :
max_children ≈ (RAM allouée au pool PHP) / (RAM moyenne par worker sous charge)
Mesurez la RAM par worker avec trafic réaliste (pas une page d''accueil vide). WordPress lourd tourne souvent entre 60 et 120 Mo par process. Laravel ou Magento montent plus haut.
Sur un VPS 8 Go où PHP peut utiliser 4 Go :
- Worker moyen : 100 Mo → max théorique 40.
- Gardez 20–30 % de marge pour OS, MySQL, Redis → visez 28–32, pas 40.
Les modes pm :
| Mode | Comportement | Cas d''usage |
|---|---|---|
| dynamic | Spawn entre min et max selon charge | Sites variables, bon compromis |
| static | Toujours max workers actifs | Charge stable, latence minimale |
| ondemand | Crée à la demande, idle timeout | RAM très contrainte, accepte cold start |
slowlog, request_terminate_timeout et erreurs fréquentes
request_slowlog_timeout (ex. 5 s) + slowlog = liste des scripts qui monopolisent les workers. Corrigez le code avant d''ajouter des process.
request_terminate_timeout coupe un script infini — utile, mais peut tronquer des imports légitimes si mal réglé.
Erreurs classiques :
- Copier un pool production sur un mutualisé — limites différentes, compte suspendu.
- Ignorer MySQL — 50 workers × requêtes lentes = 50 connexions DB saturées.
- OPcache désactivé ou mal dimensionné — chaque worker recharge le bytecode, RAM gonflée (voir OPcache).
- max_children élevé + pas de cache page — WordPress recalcule tout à chaque hit.
Le sommet : plus de workers masque une application lente
C''est le point que les offres « illimité » eludent : illimité côté visiteurs ne signifie pas illimité côté process PHP.
Décider et avancer sans angle mort
- Mesurez RAM/worker et longueur de queue sous charge réelle.
- Calculez max_children avec marge ; choisissez dynamic ou static.
- Activez slowlog, corrigez les scripts listés.
- Retestez charge et TTFB ; comparez l''hébergement seulement si le pool est sain.
Pour un diagnostic amont, lisez TTFB élevé. Pour filtrer un VPS avec accès pool complet, parcourez l''annuaire ou le comparateur.
Questions fréquentes
Comment calculer pm.max_children ?
RAM disponible pour PHP divisée par consommation moyenne d''un worker sous charge, avec marge de 20–30 %.
dynamic, ondemand ou static : que choisir ?
dynamic pour trafic variable ; static pour charge stable ; ondemand si la RAM est très limitée et que vous acceptez la latence de démarrage.
Que faire quand le slowlog remplit le disque ?
Seuil réaliste, correction des scripts, pas seulement rotation des logs.
L''hébergeur peut-il bloquer mes changements FPM ?
Oui en mutualisé ; sur VPS vous contrôlez le pool — vérifiez les limites contractuelles.
Avant d''augmenter les workers, demandez : combien de Mo par requête et combien de secondes par script ? Si vous ne savez pas, le réglage FPM est une loterie — pas de l''exploitation.