PHP Fatal error: Allowed memory size of 536870912 bytes exhausted. Le chiffre affiché correspond pourtant exactement aux 512 Mo que l’administrateur vient de configurer dans le pool PHP-FPM. Le message ne change pas d’un octet après le redémarrage du service, et la tentation est grande de conclure que la modification n’a jamais été appliquée. Ce n’est pourtant pas toujours le cas : la valeur affichée peut très bien correspondre à celle qui a été fixée, sans que ce soit elle qui a réellement provoqué l’arrêt du script.
Ce billet détaille un cas rencontré sur un pool WooCommerce dédié à l’export de commandes en CSV. Trois emplacements différents peuvent fixer une limite mémoire pour un même processus PHP, et ils ne s’appliquent pas toujours dans l’ordre auquel on pense. Comprendre lequel a eu le dernier mot évite de tourner en rond pendant une astreinte.
Le symptôme
Le script planté est une génération de facture PDF déclenchée en tâche de fond via wp_schedule_single_event. Le journal PHP-FPM affiche l’erreur avec la valeur en octets, ici 536 870 912, soit très exactement 512 Mo. La configuration du pool concerné contient bien la ligne php_admin_value[memory_limit] = 512M, vérifiée à trois reprises. Le service a été rechargé avec systemctl reload php8.1-fpm, la configuration effective a été confirmée avec php -i | grep memory_limit exécuté dans le contexte du pool concerné. Tout concorde, et pourtant l’erreur persiste identique, script après script.
Diagnostic : où chercher la limite qui bloque encore
Trois candidats peuvent fixer une limite mémoire pour une même exécution PHP, et un seul gagne : le plus restrictif de ceux qui s’appliquent réellement au contexte d’exécution.
- Le
memory_limitdu pool PHP-FPM, défini parphp_admin_valueouphp_valuedans le fichier de pool. - La constante
WP_MEMORY_LIMITdanswp-config.php, qui ne peut qu’abaisser la limite du pool, jamais la relever au-delà de ce que PHP-FPM autorise. - La constante
WP_MAX_MEMORY_LIMIT, utilisée sur les contextes admin et certains traitements en tâche de fond, avec le même plafond côté pool.
Sur ce site, wp-config.php contenait une ligne héritée d’un ancien hébergement : define('WP_MEMORY_LIMIT', '256M');. WordPress applique cette valeur via ini_set('memory_limit', ...) au chargement, et PHP l’accepte sans broncher puisqu’elle est inférieure au plafond du pool. Le message d’erreur affichait pourtant 512 Mo, pas 256 : c’est là que le cas devient intéressant.
En réalité, deux erreurs cohabitaient sur ce serveur. La première tâche plantait bien à 256 Mo à cause de la constante, et un correctif partiel avait été appliqué en modifiant uniquement le pool, sans toucher à wp-config.php. Le nouveau plantage à 512 Mo venait d’un traitement différent, un export CSV volumineux qui, lui, dépassait réellement la limite du pool. Deux symptômes identiques en apparence, deux causes distinctes, un correctif qui n’en avait résolu qu’une.
Le correctif qui a résolu le cas
Le premier réflexe a été de retirer purement et simplement la constante WP_MEMORY_LIMIT de wp-config.php, pour laisser le pool PHP-FPM faire autorité seul. Ce choix a du sens quand l’hébergeur maîtrise la configuration du pool : autant éviter deux sources de vérité qui peuvent diverger avec le temps.
Pour l’export CSV, la limite de 512 Mo restait insuffisante pour le volume réel du site (plus de 40 000 commandes historiques). Plutôt que de relever encore la limite globale du pool, le traitement a été isolé dans un pool PHP-FPM dédié aux tâches en ligne de commande, avec une limite propre de 1024 Mo, sans impact sur les requêtes web normales du même site.
# pool dédié aux exports en ligne de commande
[site-export]
user = www-data
group = www-data
listen = /run/php/site-export.sock
pm = ondemand
pm.max_children = 2
php_admin_value[memory_limit] = 1024M
Le script d’export a ensuite été invoqué avec wp eval-file export.php en ciblant explicitement ce pool via la configuration CLI de PHP, isolant ainsi le comportement mémoire du reste du site.
Prévention : éviter de rejouer cet incident
Trois habitudes limitent le risque de revivre ce type de diagnostic circulaire.
- Vérifier systématiquement
wp-config.phpavant de modifier le pool, pas l’inverse : la constante WordPress est souvent l’oubliée du correctif. - Consigner, pool par pool, quelle limite mémoire s’applique et pourquoi, dans un fichier de documentation versionné plutôt que dans la mémoire de l’équipe.
- Séparer les traitements lourds ponctuels (exports, imports, génération de PDF) dans des pools dédiés, pour ne jamais avoir à choisir entre une limite confortable pour un traitement rare et une consommation raisonnable pour le trafic courant.
Sur un pool mutualisé entre plusieurs types de tâches, ne jamais corriger un plantage mémoire sans avoir listé, dans l’ordre d’application, toutes les valeurs qui peuvent influer sur la requête concernée.
En résumé
Un message d’erreur mémoire identique peut masquer deux causes différentes exécutées à des moments distincts. Avant de relever encore une limite qui semble déjà correcte, il vaut mieux lister les trois emplacements susceptibles de la redéfinir : le pool PHP-FPM, WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT. L’opcache, de son côté, réserve une mémoire séparée via opcache.memory_consumption et ne fait jamais partie de ce calcul, un autre piège classique quand on cherche une explication du côté du cache d’instructions plutôt que du tas mémoire du script.
