# admin-ajax.php en erreur après une mise à jour du pool PHP-FPM : diagnostic

> Après une intervention serveur, les actions AJAX de l'admin WordPress renvoyaient des erreurs 502 intermittentes. Diagnostic complet du pool PHP-FPM responsable.

- Auteur : Clément Hadrot
- Publié le : 2023-01-14
- Mis à jour le : 2023-01-14
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/admin-ajax-erreur-pool-php-fpm-diagnostic/

## L’essentiel

- Une erreur 502 intermittente pointe presque toujours vers une saturation de pool
- Le nombre de processus enfants doit être dimensionné selon la RAM réelle disponible
- Les journaux PHP-FPM signalent explicitement les dépassements de capacité

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.

> L'essentiel à retenir : Une erreur 502 intermittente pointe presque toujours vers une saturation de pool ; Le nombre de processus enfants doit être dimensionné selon la RAM réelle disponible ; Les journaux PHP-FPM signalent explicitement les dépassements de capacité

## 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.