Un client a signalé un comportement agaçant sur son back-office WordPress : l’enregistrement automatique des brouillons échouait de façon aléatoire, certains clics sur des boutons AJAX de l’éditeur restaient sans réponse, et la console navigateur affichait des erreurs 502 Bad Gateway sur des requêtes vers admin-ajax.php. Le site public, lui, continuait de fonctionner normalement pour les visiteurs.
Le point de départ du diagnostic était une intervention récente : un ajustement du pool PHP-FPM effectué la veille pour limiter la consommation mémoire d’un serveur mutualisé entre plusieurs sites. L’intervention avait corrigé un problème de RAM, mais en introduisait visiblement un autre.
Symptôme : des 502 intermittents, jamais systématiques
Le caractère intermittent de l’erreur est le détail le plus révélateur ici. Une erreur systématique aurait pointé vers une configuration cassée (mauvais socket, mauvais chemin). Une erreur intermittente, qui apparaît surtout lors de pics d’activité dans l’éditeur, pointe presque toujours vers une ressource limitée qui se sature par intermittence : le nombre de processus PHP-FPM disponibles pour traiter les requêtes.
Diagnostic : consulter les journaux PHP-FPM en premier
Avant toute hypothèse, la première commande à exécuter est la lecture directe du journal du pool concerné, qui journalise explicitement les dépassements de capacité si le niveau de log le permet.
$ tail -n 50 /var/log/php8.1-fpm.log
[14-Jan-2023 11:32:07] WARNING: [pool clientb] server reached
pm.max_children setting (5), consider raising it
[14-Jan-2023 11:32:07] WARNING: [pool clientb] seems busy
(you can increase pm.start_servers, pm.min/max_spare_servers), spawning 5 children,
there are 0 idle, and 12 total children
Le message était sans équivoque : le pool avait atteint sa limite de cinq processus enfants (pm.max_children) et refusait de nouvelles connexions le temps qu’un processus se libère, provoquant côté nginx un 502 dès que le délai d’attente configuré était dépassé. La configuration du pool, ajustée la veille pour réduire la consommation mémoire globale, avait fixé cette limite trop bas pour l’usage réel du back-office.
Comprendre pourquoi admin-ajax.php sature un pool si vite
L’éditeur de blocs WordPress multiplie les appels à admin-ajax.php : sauvegarde automatique du brouillon toutes les soixante secondes, vérification des verrous de contenu (heartbeat API), chargement des révisions, actions de chaque bloc. Un ou deux rédacteurs actifs simultanément dans l’éditeur suffisent à maintenir plusieurs processus PHP-FPM occupés en continu, en plus du trafic public normal du site — une charge que le dimensionnement initial n’avait pas anticipée.
Correctif : redimensionner le pool selon la RAM réelle
Le calcul correct de pm.max_children part de la RAM disponible pour PHP-FPM divisée par la consommation moyenne d’un processus PHP (mesurable via ps --sort=-rss -o rss,cmd -C php-fpm8.1). Sur ce serveur, avec environ 45 Mo par processus et 1,5 Go de RAM allouable au pool, une limite de 25 à 30 processus était largement soutenable, contre les cinq configurés par excès de prudence.
[clientb]
pm = dynamic
pm.max_children = 25
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500
Après application et rechargement du pool (systemctl reload php8.1-fpm), les erreurs 502 ont immédiatement cessé, confirmées par une session de vingt minutes dans l’éditeur sans aucune requête AJAX en échec.
Prévention : ne jamais réduire un pool sans mesurer sa charge réelle
- Mesurer la consommation mémoire moyenne réelle d’un processus PHP avant de fixer
pm.max_children, plutôt que de deviner une valeur - Ajouter une sonde de supervision sur le message « reached pm.max_children » dans les journaux PHP-FPM de chaque pool
- Tester toute modification de pool en simulant une charge d’éditeur réaliste, pas seulement le trafic public du site
Réduire un pool PHP-FPM pour économiser de la RAM sans mesurer la charge réelle du back-office revient à déplacer le problème, pas à le résoudre.
En résumé
Une erreur 502 intermittente sur admin-ajax.php doit systématiquement faire regarder du côté du pool PHP-FPM avant d’incriminer un plugin ou l’éditeur lui-même. Les journaux du pool donnent la réponse en une ligne, à condition de les consulter en premier plutôt qu’en dernier recours.
