Erreur Allowed memory size exhausted : augmenter memory_limit PHP

L’erreur Allowed memory size of 134217728 bytes exhausted signifie qu’un script PHP a voulu utiliser plus de mémoire que ne l’autorise la directive memory_limit (134217728 octets, soit 128 Mo) : PHP l’a donc arrêté avec une Fatal error. La solution rapide consiste à porter la limite à 256M dans .user.ini, dans php.ini ou via la constante WP_MEMORY_LIMIT de wp-config.php. Si le script manque encore de mémoire à 512M, le problème ne vient pas de la limite mais d’une extension, d’un thème, d’un import ou d’une boucle, et c’est cela qu’il faut trouver.

Ce que signifie l’erreur et comment la lire

Une entrée typique du journal ressemble à ceci :

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /home/user/web/example.com/public_html/wp-content/plugins/some-plugin/includes/export.php on line 88

• of 134217728 bytes est la valeur active de memory_limit en octets. Elle permet de confirmer que votre modification a fonctionné : si vous voyez encore 134217728 après la modification, la nouvelle limite n’est pas appliquée.
• tried to allocate 20480 bytes est la taille de la dernière allocation, pas la consommation totale. Un petit nombre (quelques kilo-octets) signifie que la mémoire s’est remplie progressivement et que cette ligne n’a été que la goutte d’eau. Un grand nombre (des dizaines ou des centaines de Mo) désigne une seule opération lourde : lecture d’un gros fichier, chargement d’une table entière, traitement d’une image énorme.
• in … on line … indique où l’exécution a échoué. Un chemin dans wp-content/plugins/plugin-name désigne le suspect. Un chemin dans wp-includes signifie que le cœur de WordPress travaillait pour le compte d’une extension ou d’un thème : il faut donc creuser.

Les visiteurs d’un site WordPress voient généralement à la place le message « Il y a eu une erreur critique sur ce site », et l’administrateur reçoit un e-mail avec un lien vers le mode de récupération (voir notre guide sur l’erreur critique de WordPress). La vraie cause se trouve toujours dans le journal.

Ne la confondez pas avec Out of memory (allocated …) (tried to allocate …). PHP affiche ce message lorsque le système d’exploitation refuse de fournir de la mémoire : le serveur n’a plus de RAM ou le plafond de mémoire de tout le compte sur l’hébergement mutualisé est atteint. Augmenter memory_limit n’y changera rien.

Comment vérifier la valeur actuelle de memory_limit

La limite peut être définie à plusieurs endroits, et le site web et la ligne de commande utilisent souvent des valeurs différentes : vérifiez-la donc là où l’erreur se produit.

• WordPress : Outils → Santé du site → Infos. La section Serveur indique la limite de mémoire PHP (pour le site et pour l’administration), et la section Constantes WordPress affiche WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT.
• Un fichier de test à la racine du site affiche la limite pour les requêtes web :

<?php
// mem.php - delete it right after checking
echo 'memory_limit: ', ini_get('memory_limit'), '<br>';
echo 'PHP ', PHP_VERSION, ', SAPI: ', PHP_SAPI;

Chaque version de PHP possède son propre php.ini : vérifiez donc de nouveau après avoir basculé le site sur une autre version de PHP. En SSH, n’oubliez pas que la CLI lit un fichier distinct (sous Debian et Ubuntu /etc/php/8.3/cli/php.ini), tandis que le site tourne sous PHP-FPM avec /etc/php/8.3/fpm/php.ini :

php -i | grep memory_limit    # CLI limit, not the website's
php --ini                     # which php.ini files the CLI loads
wp eval 'echo ini_get("memory_limit"), " / ", WP_MEMORY_LIMIT, " / ", WP_MAX_MEMORY_LIMIT, PHP_EOL;'

Augmenter memory_limit : toutes les méthodes

La bonne méthode dépend de la façon dont PHP est exécuté. La plupart des hébergeurs modernes, y compris ceux qui proposent un panneau de contrôle, emploient PHP-FPM : .user.ini, php.ini et les réglages du pool fonctionnent, php_value dans .htaccess non.

.user.ini sur un hébergement mutualisé

; .user.ini in public_html
memory_limit = 256M

PHP relit ces fichiers toutes les 5 minutes (user_ini.cache_ttl = 300) : patientez, puis vérifiez avec mem.php. Utilisez uniquement K, M ou G comme unités : PHP ne comprend pas MB, et 256MB est lu comme 256 octets (à partir de PHP 8.2, un avertissement Invalid quantity est aussi écrit dans le journal). Si rien ne change, votre hébergeur a verrouillé la valeur : demandez au support de l’augmenter.

php.ini et pool PHP-FPM sur un VPS

sudo grep -n '^memory_limit' /etc/php/8.3/fpm/php.ini
sudo sed -i 's/^memory_limit = .*/memory_limit = 256M/' /etc/php/8.3/fpm/php.ini
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Pour un seul site, ajoutez la ligne dans son fichier de pool, par exemple /etc/php/8.3/fpm/pool.d/example.com.conf. Une valeur définie avec php_admin_value ne peut pas être modifiée par ini_set() : WordPress et les extensions ne peuvent donc pas l’augmenter davantage. Utilisez php_value[memory_limit] si l’application doit pouvoir le faire. Si le pool ne définit pas memory_limit, c’est php.ini qui s’applique. Si un panneau de contrôle génère les pools à partir de modèles, ne modifiez ni le modèle par défaut ni les fichiers de pool générés, car le panneau les réécrit lors des mises à jour et des reconstructions de domaine : copiez le modèle sous un nouveau nom et attribuez-le au domaine.

.htaccess : uniquement avec mod_php

php_value memory_limit 256M dans .htaccess ne fonctionne que lorsque PHP tourne comme module Apache. Avec PHP-FPM, Apache ne reconnaît pas la directive et renvoie une erreur 500 pour tout le site : si le site est tombé après l’ajout de cette ligne, supprimez-la.

wp-config.php : WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT

WP_MEMORY_LIMIT s’applique à la partie publique du site (40M par défaut, 64M en Multisite). WP_MAX_MEMORY_LIMIT s’applique aux écrans d’administration pour les administrateurs, à la décompression des mises à jour, au traitement des images et à WP-Cron (256M par défaut). WordPress n’appelle ini_set() que si sa valeur est supérieure à la limite PHP actuelle : la constante ne réduit donc jamais une limite de 512M et ne peut pas l’emporter sur une limite verrouillée par l’hébergeur.

// wp-config.php, above "That's all, stop editing!"
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

CLI : WP-CLI et Composer

php -d memory_limit=1G $(which wp) import big-export.xml --authors=create
COMPOSER_MEMORY_LIMIT=-1 composer update

Composer relève déjà sa propre limite à 1,5 Go. S’il échoue malgré tout (1610612736 dans le message), supprimez le plafond avec COMPOSER_MEMORY_LIMIT=-1, à condition que le serveur dispose d’assez de RAM. PHP 8.5 a ajouté la directive max_memory_limit : si l’administrateur du serveur l’a définie, memory_limit ne peut pas la dépasser via .user.ini ou ini_set().

Quelle quantité de mémoire définir

memory_limit est un plafond pour un seul processus PHP, pas une mémoire que le site occupe en permanence. La plupart des requêtes en utilisent bien moins ; le plafond existe pour qu’un script incontrôlé ne puisse pas accaparer tout le serveur.

Ne définissez jamais memory_limit = -1 pour un site web : un bug pourrait alors consommer toute la mémoire disponible et faire tomber tout le compte ou le serveur. Sur un VPS, prévoyez le pire cas : la limite multipliée par le nombre de processus PHP-FPM. Avec pm.max_children = 8, par exemple, un seul site à 256M pourrait théoriquement utiliser 2 Go.

Comment trouver ce qui consomme la mémoire

Si une page ordinaire a besoin de plus de 256M, augmenter la limite ne fait que repousser le problème. Ces quatre étapes permettent généralement de trouver le coupable.

Étape 1. Trouver l’entrée dans le journal

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );       // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false );  // hides errors from visitors

Sur le serveur, les erreurs PHP sont aussi enregistrées dans le journal du domaine, par exemple /var/log/apache2/domains/example.com.error.log ou /var/log/nginx/domains/example.com.error.log. Cette commande montre les fichiers qui reviennent le plus souvent :

grep -h "Allowed memory size" wp-content/debug.log /var/log/apache2/domains/example.com.error.log 2>/dev/null | grep -o "in /[^ ]*" | sort | uniq -c | sort -rn | head

Étape 2. Mesurer le pic de mémoire

Query Monitor affiche le pic de mémoire de la page dans la barre d’administration, ainsi que les requêtes SQL et les appels HTTP ventilés par extension. Sur un site en production, un petit mu-plugin enregistre les requêtes gourmandes :

<?php
// wp-content/mu-plugins/memory-peak-log.php
register_shutdown_function( function () {
    $peak = memory_get_peak_usage( true ) / 1048576;
    if ( $peak > 96 ) {
        error_log( sprintf( '[memory] %.1f MB %s', $peak, $_SERVER['REQUEST_URI'] ?? 'cli' ) );
    }
} );

Au bout d’un jour ou deux, le journal montre quelles URL approchent la limite : recherche, filtres du catalogue, admin-ajax.php ou API REST d’une extension. Supprimez le fichier une fois terminé.

Étape 3. Désactiver les extensions et changer de thème

wp plugin list --status=active    # save the list first
wp plugin deactivate --all
wp plugin activate woocommerce    # re-enable one at a time, testing the page
wp theme activate twentytwentyfive  # or another installed default theme

Sans SSH, renommez wp-content/plugins dans le gestionnaire de fichiers. L’extension Health Check & Troubleshooting peut aussi désactiver les extensions pour votre seule session, sans effet pour les visiteurs.

Étape 4. Vérifier les options autoload et les requêtes lourdes

Les options en chargement automatique (autoload) sont chargées en mémoire à chaque requête, et les restes d’extensions supprimées peuvent les faire grossir jusqu’à plusieurs mégaoctets. Depuis WordPress 6.6, Santé du site affiche un avertissement lorsqu’elles dépassent 800 Ko. Les nettoyer fait partie de l’optimisation régulière de la base de données :

wp option list --autoload=on --format=total_bytes
wp db query "SELECT option_name, LENGTH(option_value) AS bytes FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY bytes DESC LIMIT 10;"

Remplacez wp_ par le préfixe de vos tables. Dans le code d’un thème personnalisé, cherchez ‘posts_per_page’ => -1, qui charge en mémoire chaque article avec ses métadonnées.

Causes fréquentes dans WordPress

• Constructeurs de pages et thèmes lourds. Elementor exige à lui seul au moins 256 Mo, et chaque pack d’extensions complémentaires en demande davantage.
• WooCommerce avec un gros catalogue : rapports, exports de commandes, modifications de produits en masse, filtres.
• Imports et exports de milliers de lignes en une seule requête. Découpez le fichier ou lancez l’import avec WP-CLI.
• Extensions de sauvegarde qui construisent les archives en PHP. Les sauvegardes au niveau du serveur ou par cron sont plus sûres.
• Grandes images. GD garde chaque pixel en mémoire sur 4 octets : une photo de 6000 × 4000 pixels nécessite donc environ 96 Mo avant même la création des miniatures. Redimensionnez les photos à 2560 px sur le grand côté avant de les téléverser : c’est le seuil big_image_size_threshold à partir duquel WordPress réduit lui-même les images.
• Scanners de sécurité et extensions d’articles similaires qui parcourent chaque fichier ou chaque article en une seule passe.
• Bugs dans le code : boucles infinies, récursion, tableaux qui grossissent dans une boucle.

Hébergement mutualisé ou VPS : quand la limite ne veut pas monter

Sur un hébergement mutualisé, memory_limit s’applique par processus, mais l’hébergeur plafonne généralement aussi la mémoire totale du compte. Quand plusieurs processus utilisent 256 Mo en même temps, vous atteignez ce plafond et voyez à la place des erreurs 500, 503 ou 508. Découvrez comment fonctionne l’hébergement mutualisé et comment le cache et la RAM influencent la vitesse. Ce que vous pouvez faire : définir memory_limit dans .user.ini ou dans les réglages PHP du panneau, mettre les pages en cache, alléger la liste des extensions, déplacer les imports et sauvegardes vers cron ou WP-CLI, et passer à une offre supérieure ou à un VPS si la mémoire manque en permanence.

Sur un VPS, vous maîtrisez php.ini, les pools et le nombre de processus. Gardez « memory_limit × pm.max_children » pour l’ensemble des sites, plus MySQL et le système, en dessous de la RAM totale. Taille moyenne réelle d’un processus PHP-FPM :

ps -C php-fpm8.3 -o rss= | awk '{s+=$1; n++} END {print s/n/1024 " MB"}'

FAQ

Puis-je définir memory_limit = -1 ?

Pour une tâche CLI ponctuelle sur votre propre serveur, oui. Pour un site web, non : un script incontrôlé consommerait toute la mémoire et ferait planter tout le site ou le serveur au lieu d’échouer seul.

Pourquoi WP_MEMORY_LIMIT dans wp-config.php ne fonctionne-t-il pas ?

Généralement pour l’une de ces trois raisons : la constante est définie après le chargement de wp-settings.php, l’hébergeur a verrouillé la limite avec php_admin_value, ou votre valeur n’est pas supérieure à la limite PHP actuelle. WordPress ne fait qu’augmenter la limite, il ne la réduit jamais.

Pourquoi l’erreur n’apparaît-elle que dans l’administration ou pendant les mises à jour ?

C’est là que se fait le travail le plus lourd : décompression des mises à jour, traitement des images, imports, constructeurs de pages. Si l’hébergeur ne laisse pas WordPress porter la limite à WP_MAX_MEMORY_LIMIT, la mémoire s’épuise précisément à ces moments-là.

Un memory_limit plus élevé rendra-t-il mon site plus rapide ?

Non. Ce n’est qu’un plafond pour un processus. Si votre site WordPress est lent, le cache de pages, OPcache et un stockage rapide sont utiles ; sur un VPS, une limite surdimensionnée ne fait qu’augmenter le risque de manquer de RAM.

OPcache et Redis comptent-ils dans memory_limit ?

Non. OPcache utilise une mémoire partagée distincte (opcache.memory_consumption), et Redis ou Memcached tournent comme des services séparés. Seule compte la mémoire que le script PHP alloue pendant la requête, y compris les données qu’il a récupérées depuis un cache.

Conclusion

Allowed memory size exhausted signifie qu’un script a atteint son plafond de mémoire. Portez memory_limit à 256M avec la méthode que votre serveur prend en charge (.user.ini avec PHP-FPM, php.ini ou le pool sur un VPS, WP_MEMORY_LIMIT en complément), vérifiez que la nouvelle valeur est active et, si la mémoire manque toujours, trouvez le coupable grâce au journal, à Query Monitor et à la désactivation des extensions une par une. Si votre site a dépassé ses ressources, comparez les offres d’hébergement mutualisé RichHost avec stockage NVMe et panneau de contrôle maison avec assistant IA, ou découvrez ce qui compte pour un bon hébergement WordPress.