Nginx affiche upstream timed out while reading response header from upstream. PHP-FPM indique listen queue len 32. Réflexe immédiat : passer pm.max_children de 50 à 150. Le trafic est absorbé — la RAM monte à 98 %, l'OOM killer frappe MySQL. Cause jamais traitée : un webhook paiement synchrone de 25 secondes par commande.
PHP-FPM saturé présente deux maladies aux symptômes similaires : vraiment pas assez de workers pour une charge CPU courte, ou workers bloqués sur entrée-sortie réseau, requête SQL lente, verrou fichier. Confondre les deux coûte cher en RAM — et masque le vrai goulot pendant des semaines.
Si le slowlog montre la même trace d'appel partout, ce n'est pas un problème FPM — c'est cette trace d'appel.
La règle d'or : slowlog vingt-quatre heures, puis réglage pm — jamais l'inverse. Monter max_children sans raccourcir le chemin critique, c'est embaucher des caissiers alors que chaque client paie encore en chèque sans provision.
Lire php-fpm status et slowlog
Activez d'abord la visibilité :
pm.status_path = /fpm-status
ping.path = /fpm-ping
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log
Protégez /fpm-status derrière nginx — ne l'exposez pas publiquement. Signaux de saturation :
active processes≈ max en permanence ;listen queue> 0 ;- journaux
server reached pm.max_children.
Formule RAM : (max_children × mémoire par enfant) + OS + MySQL < RAM totale — marge 20 % minimum.
Diagnostic A vs B : workers insuffisants ou code bloquant
A — workers insuffisants : requêtes inférieures à 200 ms, processeur PHP élevé, slowlog vide ou traces diversifiées → monter pm.max_children par paliers de dix, en surveillant la RAM.
B — code bloquant : workers actifs, processeur bas, slowlog concentré sur la même ligne (curl, PDO, file_get_contents) → mettre en file d'attente asynchrone, timeout curl trois à cinq secondes, corriger l'index SQL — voir index MySQL manquant et profiling PHP.
Alignez fastcgi_read_timeout nginx avec la réalité applicative — un timeout nginx plus court que le webhook masque le problème en 504 sans slowlog. Sur mutualisé, un plafond de processus imposé par l'hébergeur est un signal d'upgrade VPS plutôt que de tuning infini.
Pour les requêtes N+1, voir MySQL site dynamique — une boucle de requêtes peut bloquer tous les workers sans CPU élevé.
Tuning pm : dynamic, ondemand, static
| Mode | Quand l'utiliser | Risque |
|---|---|---|
| dynamic | Trafic variable, RAM maîtrisée | Pics imprévus si max_children trop bas |
| ondemand | Trafic sporadique, RAM limitée | Latence au démarrage à froid |
| static | Charge plate, RAM prévisible | Gaspillage si trafic creux |
Commencez par pm = dynamic avec pm.max_children calculé sur la formule RAM. Testez ondemand seulement si la latence au démarrage à froid est acceptable pour votre audience.
Le sommet : plus de workers avec code bloquant
Comparez les VPS où vous contrôlez PHP-FPM via l'annuaire. Sur un mutualisé, le plafond de processus est non négociable — le diagnostic reste le même, mais la solution passe par l'upgrade ou l'optimisation code.
Décider et avancer sans angle mort
Avant d'augmenter max_children :
- Activez status et slowlog — sans visibilité, vous tunez à l'aveugle.
- Classifiez la saturation : processeur élevé (A) ou workers occupés processeur bas (B).
- Corrigez le code ou le SQL si le slowlog est concentré — pas de tuning pm avant correction.
- Ajustez pm.max_children par paliers de dix avec budget RAM documenté.
- Alignez fastcgi_read_timeout nginx et timeouts applicatifs (curl, PDO).
- Testez en charge le même endpoint après correction — la file d'attente doit rester à zéro sous charge normale.
Questions fréquentes
Comment savoir si PHP-FPM est saturé ?
listen queue supérieure à zéro, journaux max_children atteint, erreurs 502/504 nginx, latence linéaire avec le trafic. Activez pm.status_path pour observer avant la panne — pas seulement après.
Augmenter max_children suffit-il ?
Temporairement pour le diagnostic A. Calculez la RAM disponible ; si le slowlog est concentré, corrigez le code d'abord — doubler les workers avec code bloquant provoque un OOM kill.
Comment repérer code bloquant ?
slowlog PHP-FPM et outil de profilage. Symptôme : tous les workers occupés, processeur bas. Même trace partout = goulot identifié — pas un manque de workers.
ondemand vs dynamic ?
dynamic ou ondemand pour trafic variable ; static pour charge plate. ondemand économise la RAM mais ajoute de la latence au démarrage — testez en préproduction.
PHP-FPM saturé raconte soit un manque de caisses — soit des caissiers immobiles. Confondre les deux coûte cher en RAM.