Allowed memory size exhausted : augmenter la mémoire PHP

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

En anglais : Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)

Le message « Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) » est une erreur fatale de PHP. Il apparaît dans le journal, et sur le site il se traduit selon le cas par la page d’erreur critique, par un écran blanc ou par une erreur 500. Les nombres changent d’un site à l’autre, mais le sens est le même : un script a voulu utiliser plus de mémoire que PHP ne l’y autorise.

Le message n’est pas traduit : PHP l’écrit en anglais, y compris sur un site en français, suivi du fichier et de la ligne concernés. Il peut surgir sur le site public, dans l’administration, pendant une importation, une mise à jour, une tâche planifiée ou une commande WP-CLI.

Ce que signifie cette erreur

Chaque exécution de PHP dispose d’un plafond de mémoire, fixé par la directive memory_limit. Quand un script dépasse ce plafond, le moteur PHP (et non WordPress) interrompt l’exécution avec une erreur fatale. Le message se lit ainsi :

• Allowed memory size of N bytes : la limite en vigueur, en octets ;
• tried to allocate M bytes : la dernière réservation refusée. Un petit nombre signifie que le script a déjà tout consommé en petits morceaux ; un grand nombre désigne une seule opération massive (une image décompressée, un très gros tableau, une réponse énorme).

Valeur affichée (octets)	Limite correspondante
33554432	32M
41943040	40M (valeur par défaut de WordPress)
67108864	64M
134217728	128M
268435456	256M
536870912	512M

WordPress intervient seulement pour relever la limite. Dans wp-includes/default-constants.php, wp_initial_constants() définit WP_MEMORY_LIMIT (40M par défaut, 64M en multisite) et WP_MAX_MEMORY_LIMIT (256M par défaut). Si la limite de PHP est inférieure à WP_MEMORY_LIMIT, WordPress l’augmente avec ini_set() ; si elle est supérieure, il ne la baisse jamais. Dans l’administration, wp_raise_memory_limit( 'admin' ) (appelée par wp-admin/admin.php) la porte jusqu’à WP_MAX_MEMORY_LIMIT pour les tâches lourdes. Ce mécanisme ne fonctionne que si l’hébergeur autorise ini_set() sur memory_limit.

Diagnostic rapide

Symptôme / constat	Cause probable	À vérifier
Le journal cite un fichier d’extension ou de thème	Extension ou thème gourmand ou boucle infinie	Chemin dans debug.log, désactivation de l’extension
L’erreur survient pendant un import, une génération de miniatures ou un export	Opération portant sur un gros volume	Taille des fichiers, import par lots
« tried to allocate » affiche un très grand nombre	Une seule opération massive (image, tableau, réponse)	Dimensions de l’image, requête sans limite
Rien ne change après avoir modifié wp-config.php	Limite imposée par PHP-FPM ou l’hébergeur	Valeur réelle dans Santé du site, pool PHP-FPM
Erreur uniquement en ligne de commande (WP-CLI)	Configuration PHP différente pour la CLI	php --ini, mémoire de la CLI
Seule l’administration est concernée	Limite d’administration plus basse que prévu	WP_MAX_MEMORY_LIMIT

Les causes les plus fréquentes

1. Une limite trop basse pour le site : 64M ou 128M ne suffisent plus avec un constructeur de pages, WooCommerce ou plusieurs extensions lourdes.
2. Une extension gourmande ou mal écrite, qui charge trop de données en mémoire (requêtes sans pagination, tableaux géants).
3. Un traitement d’images : une photo de 6 000 × 4 000 px occupe près de 100 Mo une fois décompressée, avant les copies nécessaires aux miniatures.
4. Un import, un export ou une tâche planifiée qui traite tout d’un bloc au lieu de procéder par lots.
5. Une boucle infinie ou une récursion qui remplit la mémoire jusqu’au plafond.
6. Une limite imposée au-dessus de WordPress par l’hébergeur, par le pool PHP-FPM ou par la configuration de la CLI.

Solutions pas à pas

Vous modifiez des fichiers de configuration : copiez-les avant de les éditer. Du moins invasif au plus technique :

1. Connaître la limite réellement appliquée

Dans l’administration, ouvrez Outils > Santé du site > Info > Serveur : la ligne « Limite de mémoire PHP » indique la valeur en vigueur. Sans accès à l’administration, utilisez WP-CLI, tout en sachant que la CLI peut avoir un php.ini différent de celui du site :

wp eval 'echo ini_get( "memory_limit" ), PHP_EOL;'
php --ini

2. Relever la limite depuis wp-config.php

C’est la solution la plus simple, utilisable même sur un hébergement mutualisé. Ajoutez ces lignes dans wp-config.php, au-dessus de la ligne « That’s all, stop editing! Happy publishing. » :

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT s’applique à tout le site, WP_MAX_MEMORY_LIMIT aux écrans d’administration. Rechargez la page et vérifiez la valeur dans Santé du site. Si elle ne change pas, l’hébergeur bloque ini_set() : passez à l’étape 3.

3. Relever memory_limit dans la configuration de PHP

Selon votre hébergement, utilisez l’une de ces méthodes. Dans le php.ini ou un fichier de configuration dédié :

memory_limit = 256M

Dans un fichier .user.ini à la racine du site (PHP en CGI/FPM ; PHP relit ce fichier toutes les 300 secondes par défaut) :

memory_limit = 256M

Dans le .htaccess, uniquement si PHP tourne comme module Apache (sinon la directive provoque une erreur 500) :

php_value memory_limit 256M

Équivalent nginx / PHP-FPM : nginx ne gère pas la mémoire de PHP. Modifiez le pool PHP-FPM (par exemple /etc/php/8.3/fpm/pool.d/www.conf, le chemin dépend de la version), puis rechargez le service :

php_admin_value[memory_limit] = 256M
; puis :
; sudo systemctl reload php8.3-fpm

Si la valeur persiste à rester basse malgré ces réglages, lisez notre article sur la limite qui persiste côté PHP-FPM. Notez qu’une directive php_admin_value ne peut pas être contournée par WP_MEMORY_LIMIT.

4. Trouver ce qui consomme

Relever la limite masque le symptôme ; si l’erreur revient, cherchez la cause :

• dans wp-content/debug.log, repérez le fichier cité par « PHP Fatal error: Allowed memory size » : son dossier indique l’extension ou le thème concerné ;
• installez Query Monitor sur un environnement de test pour mesurer la mémoire par page et repérer les requêtes lourdes ;
• désactivez les extensions une par une (wp plugin deactivate nom-de-l-extension) et observez la consommation ;
• cherchez les requêtes sans limite, comme posts_per_page => -1 sur de gros volumes ; préférez la pagination et, quand seuls les identifiants servent, 'fields' => 'ids' dans WP_Query.

Notre article sur le pic de mémoire après un plugin de sécurité détaille une méthode d’isolement.

5. Traiter les gros volumes par lots

Pour un import ou un export, découpez le fichier, ou utilisez une extension qui traite par paquets. Pour les images, réduisez les dimensions avant l’envoi. Une tâche planifiée qui échoue se règle dans le code : voir cet exemple de cron d’extension trop gourmand.

6. Cas de WP-CLI et des commandes planifiées

La ligne de commande lit souvent un php.ini distinct, avec une limite différente. Passez la limite à la volée :

php -d memory_limit=512M "$(command -v wp)" plugin list
# ou, pour toutes les commandes de la session :
export WP_CLI_PHP_ARGS='-d memory_limit=512M'

Voir l’article « PHP Fatal error: Allowed memory size » côté WP-CLI.

7. Si rien ne change : plafond de l’hébergeur ou noyau

Si la limite réelle reste inférieure à celle demandée, l’offre d’hébergement la plafonne : demandez au support de la relever ou changez d’offre. Si le processus disparaît sans message PHP, le noyau a peut-être arrêté PHP faute de mémoire : consultez sudo dmesg | grep -i 'out of memory' et l’article sur l’OOM killer et PHP-FPM.

Prévenir l’erreur

• Choisissez une limite adaptée : 256M convient à la plupart des sites, davantage pour une boutique ou un constructeur de pages chargé.
• Évitez memory_limit = -1 : sans plafond, une boucle infinie peut épuiser la mémoire du serveur entier.
• Mesurez avant d’installer : testez une nouvelle extension en préproduction avec Query Monitor.
• Traitez les gros volumes par lots et compressez les images avant l’envoi.
• Surveillez la mémoire du serveur et le journal d’erreurs PHP pour repérer les dérives avant la panne.

Questions fréquentes