Fatal error de mémoire PHP : trouver le script gourmand avant de relever la limite

Fatal error allowed memory size 268435456 bytes exhausted : PHP stoppe un script dont la memory limit de 256 Mo est épuisée, un byte valant un octet. Sur un site WordPress, cette error de mémoire PHP vient le plus souvent d'une extension, d'un export ou d'une boucle, bien avant la limit du serveur.

Que veut dire le message mot à mot ?

Le message « Allowed memory size of 268435456 bytes exhausted » se lit ainsi : la taille de mémoire autorisée (allowed memory size), 268 435 456 octets, est épuisée (exhausted). Le calcul est exact : 256 × 1 024 × 1 024 = 268 435 456, soit 256 Mo. Sur un serveur, la ligne complète du journal ressemble à ceci :

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /home/site/public_html/wp-includes/class-wpdb.php on line 2187

La mention « tried to allocate 20480 bytes » indique la demande qui a fait déborder le script, ici 20 Ko. Une petite allocation qui échoue montre que la mémoire s'est remplie peu à peu, par une boucle ou un tableau qui grossit. Une allocation énorme d'un coup, de plusieurs dizaines de Mo, pointe vers une opération précise : une image décompressée, un fichier lu en entier, une réponse d'API chargée d'un bloc. Le chemin et la ligne (« on line ») désignent l'endroit où la mémoire a manqué, pas forcément celui qui l'a consommée : le fichier cité appartient souvent au cœur de WordPress ou à une bibliothèque, alors que la fuite vient d'une extension qui l'appelle des milliers de fois.

D'après le manuel de php.net, la valeur par défaut de memory_limit est 128M. Un serveur réglé sur 256M a donc déjà reçu une hausse, ce qui oriente vers une consommation anormale plutôt que vers un réglage trop serré.

Pourquoi 256 Mo revient si souvent sur un site WordPress

La limite de 256 Mo n'est pas un hasard sur un site WordPress : c'est la valeur par défaut de la constante WP_MAX_MEMORY_LIMIT, que WordPress applique dans l'administration. La documentation de WordPress pour les développeurs décrit deux constantes distinctes. WP_MEMORY_LIMIT vaut 40M sur un site simple et 64M sur un réseau multisite, pour les pages publiques ; WP_MAX_MEMORY_LIMIT vaut 256M et sert aux tâches lourdes du tableau de bord, comme le traitement d'une image envoyée dans la médiathèque.

WordPress ne fait que demander davantage de mémoire à PHP : si le serveur fixe une limite plus haute, il la garde, et si le serveur interdit la hausse, la constante reste sans effet. Une erreur à 268435456 bytes qui survient seulement dans l'administration (import, export, régénération des miniatures, mise à niveau d'une extension) vient donc très souvent de ce plafond de 256M, même quand le php.ini annonce une autre valeur.

Depuis la version 5.2, WordPress intercepte ces erreurs fatales : au lieu d'une page blanche, le visiteur lit « Il y a eu une erreur critique sur ce site » et l'administrateur reçoit un courriel avec un lien vers le mode de récupération, qui désactive l'extension ou le thème en cause pour sa seule session. Ce courriel cite souvent le fichier fautif : c'est le premier indice à relever. Quand la page reste blanche ou renvoie un code 500 sans message, la méthode pour trouver l'origine d'une erreur 500 PHP aide à faire apparaître la ligne exacte dans le journal.

Trouver le script qui consomme la mémoire

Un script PHP qui épuise 256 Mo relève presque toujours d'une de ces familles de causes, à vérifier dans cet ordre sur un site hébergé :

• une boucle sans fin ou une récursion qui ne s'arrête pas, par exemple un hook WordPress qui déclenche l'action qui le rappelle ;
• un résultat SQL chargé en entier avec fetchAll() ou un WP_Query sans pagination sur des centaines de milliers de lignes, au lieu d'une lecture ligne par ligne ;
• une grande photo traitée par GD ou Imagick : l'image est décompressée en mémoire, et une prise de vue de 6 000 sur 4 000 pixels occupe à elle seule environ 92 Mo à quatre octets par pixel, avant toute copie ;
• un export, une sauvegarde ou une importation lancés depuis l'administration, qui construisent tout le fichier en mémoire avant de l'écrire ;
• une extension récente ou incompatible avec la version de PHP du serveur, qui boucle sur un cas qu'elle ne gère pas.

Pour confirmer, la mesure vaut mieux que l'intuition. Le pic atteint par un script s'écrit dans le journal d'erreurs avec une seule ligne placée en fin de traitement :

error_log('Pic mémoire : ' . round(memory_get_peak_usage(true) / 1048576) . ' Mo');

Placée à plusieurs étapes d'un script, la fonction memory_get_usage() montre à quel moment la consommation s'envole ; depuis PHP 8.2, memory_reset_peak_usage() remet le compteur de pic à zéro entre deux étapes. Sur WordPress, désactiver les extensions une à une sur une copie du site isole la coupable en quelques essais. Le journal d'erreurs de PHP, accessible depuis le panneau de l'hébergement, indique aussi l'heure et l'adresse de chaque erreur : une tâche planifiée nocturne ne se traite pas comme une page vue par tous les visiteurs.

Corriger le code plutôt que la configuration

Un code PHP qui lit trop de données à la fois se corrige en traitant les données par lots. Un générateur (le mot-clé yield) renvoie les lignes une par une sans les garder toutes ; avec PDO et MySQL, l'attribut PDO::MYSQL_ATTR_USE_BUFFERED_QUERY à false évite de charger tout le résultat côté PHP. Dans WordPress, une requête qui ne demande que les identifiants ('fields' => 'ids') et qui renonce au comptage total ('no_found_rows' => true) consomme une fraction de la mémoire d'une requête complète. Pour un fichier volumineux, fopen() et fgets() lisent ligne par ligne là où file_get_contents() charge tout le contenu.

Où relever memory_limit selon l'hébergement

La limite memory_limit se relève à plusieurs niveaux, du plus général au plus local, quand le besoin est légitime : une boutique avec beaucoup de déclinaisons de produits, un import de catalogue, un traitement d'images en lot. Le bon niveau dépend de la façon dont PHP tourne sur le serveur.

Un hébergement mutualisé impose souvent un plafond que ces réglages ne franchissent pas : la valeur demandée s'affiche parfois, mais le processus reste bridé par le service. Après chaque modification, une page appelant phpinfo() montre la valeur réellement appliquée ; il faut la supprimer ensuite, car elle expose la configuration du serveur. Sur WordPress, l'écran Outils, Santé du site, onglet Informations, rubrique Serveur, affiche la limite de mémoire PHP (« PHP memory limit » dans l'interface anglaise) sans fichier à créer. En ligne de commande, php -i | grep memory_limit donne la valeur du PHP CLI, et php --ini liste les fichiers de configuration qu'il charge.

Composer, le gestionnaire de dépendances, produit la même fatal error lors d'un composer update sur un gros projet. Sa documentation indique qu'il tente de lui-même de porter la limite à 1,5 Go, ce qui explique les messages à 1610612736 bytes ; la variable d'environnement COMPOSER_MEMORY_LIMIT=-1 lève la limite pour une seule exécution.

Demander de l'aide sur un forum anglophone

Les réponses les plus détaillées sur l'erreur allowed memory size exhausted se trouvent sur Stack Overflow, Server Fault et le forum de support de WordPress.org, en anglais. Une question bien posée obtient une réponse utile ; une question vague reçoit le conseil de relever la limite, qui ne règle rien si une boucle consomme la mémoire. Une demande efficace contient la ligne complète du message (avec « tried to allocate » et le numéro de ligne), la version de PHP, la valeur de memory_limit lue dans phpinfo(), le type d'hébergement et l'action qui déclenche l'erreur. Un modèle de titre et de premier paragraphe :

Allowed memory size of 268435456 bytes exhausted with WooCommerce CSV export
I raised memory_limit to 512M but the error still appears on our shared hosting service.
How should I find which plugin or code uses the memory? PHP 8.2, WordPress 6.x.

Quand le fichier cité dans le message appartient à une extension précise, le bon canal est son forum de support ou, pour un projet hébergé sur GitHub, une issue sur son dépôt : les développeurs y repèrent vite un problème déjà signalé et parfois corrigé dans une version suivante. Avant de publier, chercher la phrase exacte du message avec le nom de l'extension fait souvent remonter une question related déjà résolue.

Les termes anglais des réponses sur la mémoire PHP

Les réponses anglophones sur cette erreur de mémoire emploient un vocabulaire récurrent, qu'il vaut mieux connaître avant de suivre un conseil à la lettre :

shared hosting, web hosting, hosting provider

L'hébergement mutualisé, l'hébergement web et l'hébergeur. Une réponse qui commence par « on shared hosting, you may not be able to… » rappelle que l'hébergeur fixe des server limits que le site ne dépasse pas, quel que soit le fichier modifié.

increase memory limit, more memory

Relever memory_limit pour donner plus de mémoire au script. La consigne est valable quand le besoin est mesuré, but it should not be the first step : sans mesure, la même erreur revient au prochain import plus gros.

current memory limit, check memory limit

La valeur réellement appliquée, lue avec ini_get('memory_limit') ou dans phpinfo(). Un tool de diagnostic comme l'écran Santé du site de WordPress l'affiche aussi.

memory leak

Une fuite de mémoire : un process qui garde des données dont il n'a plus besoin. Chaque requête PHP servie par le serveur web repart à zéro, si bien qu'une fuite se voit surtout dans les traitements longs, en ligne de commande, dans un worker de file d'attente ou un import qui tourne pendant des heures.

large datasets

Les gros volumes de données, à traiter par lots (batch processing) plutôt qu'en un seul tableau.

accepted answer

La réponse validée par l'auteur de la question sur Stack Overflow. Elle n'est pas toujours la meilleure aujourd'hui : une réponse de 2012 peut ne plus fonctionner avec PHP 8, et la date du post compte autant que son nombre de votes.

Quand l'erreur suit un changement de version de PHP

Une erreur de mémoire PHP qui apparaît juste après une migration vers une version plus récente vient rarement de la limite elle-même. Une extension écrite pour une ancienne version peut entrer dans une boucle sur une fonction dont le comportement a évolué, ou accumuler des avertissements dans un tableau jusqu'à saturer la mémoire. La méthode pour tester la compatibilité d'un site avec PHP 7 et 8 sur une copie permet de repérer le code en cause avant de basculer le site en production. Relever memory_limit dans ce cas masque le défaut et repousse seulement l'erreur au prochain pic.

Les autres limites d'un hébergement, durée d'exécution maximale et taille des envois notamment, se règlent avec la même logique et sont présentées dans la rubrique PHP et serveurs de R7.

memory_limit à -1, CLI et cache : trois réglages trompeurs

Peut-on mettre memory_limit à -1 pour ne plus voir l'erreur ?

Le manuel de php.net indique que la valeur -1 supprime toute limite. Sur un serveur partagé, c'est le moyen le plus sûr de laisser un script défaillant épuiser la mémoire de toute la machine. Cette valeur se réserve aux scripts en ligne de commande dont la consommation est connue et surveillée.

Pourquoi la valeur affichée diffère-t-elle de celle réglée ?

PHP en ligne de commande et PHP servi par le serveur web lisent souvent deux fichiers de configuration différents. Un .user.ini n'est relu qu'après le délai fixé par user_ini.cache_ttl, 300 secondes par défaut, et une valeur posée avec php_admin_value dans le pool PHP-FPM l'emporte sur tout réglage du site.

Le site reste lent une fois l'erreur corrigée, est-ce lié ?

Une page qui frôle la limite de mémoire est souvent une page lente : les mêmes requêtes trop larges ralentissent l'affichage. Les causes d'un WordPress trop lent se vérifient alors une par une, cache et base de données en tête.

Sources : manuel de php.net, directives du noyau (memory_limit), fonctions memory_get_peak_usage(), memory_reset_peak_usage() et ini_set(), section .user.ini ; documentation de WordPress pour les développeurs, fichier wp-config.php (WP_MEMORY_LIMIT, WP_MAX_MEMORY_LIMIT) ; documentation de Composer, rubrique Troubleshooting, Memory limit errors.