Le problème à résoudre
PHP-FPM exécute les requêtes dynamiques de WordPress dans un ensemble de processus. Trop peu de workers crée une file d’attente ; trop de workers peut épuiser la mémoire et déclencher le swap ou l’arrêt du système.
Le dimensionnement part d’une mesure : mémoire réellement consommée par un worker sous une charge représentative, puis budget disponible après système, serveur web, base et cache.
Reconnaître les bons signaux
| Signal observé | Interprétation probable | Premier contrôle |
|---|---|---|
| max_children reached | Tous les workers occupés | Lire journal et file |
| Swap actif | Trop de mémoire engagée | Réduire concurrence ou poids |
| Requêtes longues | Plugin, SQL ou API externe | Activer slowlog |
Les notions à maîtriser
- pm=dynamic garde un nombre variable de workers prêts ; ondemand les crée à la demande.
- pm.max_children fixe la concurrence maximale et doit respecter le budget mémoire.
- request_terminate_timeout limite une requête bloquée mais peut interrompre une tâche légitime.
- Le slowlog capture la pile des requêtes dépassant un seuil et aide au diagnostic.
Méthode de diagnostic
Plan d’action recommandé
- Fixer max_children à partir du budget mémoire, puis tester.
- Ajuster start_servers et spare_servers pour les pointes prévisibles.
- Activer status, ping et slowlog avec accès restreint.
- Configurer des timeouts cohérents entre proxy, serveur web et FPM.
- Revoir le réglage après ajout de plugins ou changement de trafic.
Commandes de contrôle
Adaptez 8.3 à la version installée. La première commande vérifie le service ; les suivantes affichent les événements récents et les processus classés par mémoire.
systemctl status php8.3-fpm --no-pager
journalctl -u php8.3-fpm --since '30 minutes ago' --no-pager
ps -ylC php-fpm8.3 --sort:rssNe calculez pas pm.max_children sur une seule mesure au repos : utilisez une charge représentative et gardez de la mémoire pour le système, la base et le cache.
Erreurs fréquentes à éviter
- Multiplier max_children parce que le CPU semble disponible.
- Utiliser un timeout court pour masquer une requête lente.
- Exposer publiquement la page de statut PHP-FPM.
Indicateurs à suivre
| Indicateur | Repère | Pourquoi le suivre |
|---|---|---|
| Listen queue | 0 hors pointes très brèves | Détecte l’attente |
| Max children reached | 0 en régime normal | Signale la limite |
| RSS worker | Mesurée au p95 | Dimensionne la mémoire |
Checklist avant validation
- Une mesure de référence est conservée.
- Le changement est testé hors production lorsque c’est possible.
- Une sauvegarde ou un retour arrière est disponible.
- Les dépendances web, e-mail et DNS ont été contrôlées.
- Les journaux et alertes sont surveillés après intervention.
- Le résultat est documenté avec date et responsable.
Questions fréquentes
Quel mode pour WordPress ?
dynamic convient souvent à une charge régulière ; ondemand peut aider les petits sites peu sollicités.
Comment calculer max_children ?
Budget mémoire FPM divisé par consommation prudente d’un worker, avec marge système.
Plus de workers accélère-t-il le site ?
Seulement si les requêtes attendent et que CPU, base et mémoire peuvent suivre.
Sources techniques
Pour vérifier les règles et approfondir le sujet :
Besoin de dimensionner PHP-FPM ?
L’analyse doit relier mémoire, file d’attente et requêtes lentes avant de modifier les workers.
Voir l’infogérance Linux