Sur un serveur dédié, une limite mémoire PHP mal configurée peut provoquer des erreurs difficiles à diagnostiquer : page blanche, erreur 500, tâche WP-CLI interrompue, import bloqué, traitement WooCommerce incomplet ou message dans les logs.
Sur les anciens serveurs PHP équipés de Suhosin, on pouvait aussi rencontrer une alerte de ce type dans les logs Apache ou syslog :
Dec 12 16:19:26 mail suhosin[22860]: ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value (attacker '82.83.84.85', file '/home/skyminds/public_html/wp-admin/admin.php', line 96)Code language: JavaScript (javascript)
Ce message indique qu’un script PHP a tenté d’augmenter sa limite mémoire à 268435456 octets, soit 256M, mais que Suhosin l’a refusé parce que sa propre limite était plus basse.
Aujourd’hui, Suhosin concerne surtout des environnements legacy. Sur les serveurs modernes, on règle plutôt la limite mémoire via php.ini, PHP-FPM, Apache, le pool FPM, la CLI, WordPress ou le panneau d’hébergement. La logique reste toutefois la même : la limite effective dépend du bon fichier, du bon SAPI et parfois d’une limite supérieure imposée ailleurs.
À quoi sert memory_limit dans PHP ?
La directive memory_limit définit la quantité maximale de mémoire qu’un script PHP peut allouer. Le manuel PHP précise que cette directive sert à empêcher les scripts mal écrits de consommer toute la mémoire disponible sur un serveur. Voir la documentation PHP sur memory_limit.
Exemple classique dans un fichier php.ini :
memory_limit = 256M
Une valeur trop basse peut bloquer certaines opérations légitimes. Une valeur trop haute peut permettre à trop de processus PHP de consommer toute la RAM du serveur. Comme souvent côté infra, le bon réglage est un compromis, pas un concours de gros chiffre.
Reconnaître une erreur PHP memory_limit
Une erreur de limite mémoire ressemble souvent à ceci :
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 4096 bytes)
La valeur 134217728 correspond à 128M. La valeur 268435456 correspond à 256M. PHP affiche souvent les valeurs en octets dans les logs, ce qui donne tout de suite un air plus dramatique à l’erreur.
Sur un site WordPress, l’erreur peut apparaître lors :
- d’un import ou export volumineux ;
- d’une génération d’images ;
- d’un traitement WooCommerce ;
- d’une tâche cron ;
- d’un scan de sécurité ;
- d’une mise à jour de plugin ;
- d’une commande WP-CLI ;
- d’un constructeur de pages trop gourmand ;
- d’un plugin qui charge trop de données en mémoire.
Première étape : trouver le bon php.ini
Le piège classique consiste à modifier le mauvais fichier php.ini. Sur un même serveur, PHP peut avoir plusieurs configurations selon le contexte :
- PHP en ligne de commande, ou CLI ;
- PHP-FPM pour nginx ou Apache avec proxy_fcgi ;
- mod_php avec Apache ;
- plusieurs versions de PHP installées en parallèle ;
- un pool PHP-FPM spécifique par site ;
- un fichier
.user.inidans un répertoire web.
Pour connaître le fichier utilisé par PHP en ligne de commande :
php --ini
Pour lire la valeur CLI de memory_limit :
php -i | grep -i '^memory_limit'Code language: JavaScript (javascript)
Mais attention : cette valeur concerne la CLI. Elle ne garantit pas que votre site web utilise le même fichier.
Vérifier la configuration PHP utilisée par le site web
Pour savoir quel fichier php.ini est utilisé par le site web, créez temporairement un fichier de diagnostic :
<?php
phpinfo();Code language: HTML, XML (xml)
Placez-le par exemple dans un fichier nommé phpinfo.php, ouvrez-le dans le navigateur, puis cherchez :
Loaded Configuration File;Scan this dir for additional .ini files;Additional .ini files parsed;Server API;memory_limit.
Supprimez ce fichier dès que vous avez terminé :
rm phpinfo.phpCode language: CSS (css)
phpinfo() expose beaucoup d’informations sur le serveur. Il est utile cinq minutes, pas cinq mois.
Configurer memory_limit avec Apache et mod_php
Sur un ancien serveur Apache avec mod_php, le fichier pouvait ressembler à ceci :
/etc/php5/apache2/php.ini
Sur une version moderne de Debian ou Ubuntu, le chemin ressemble plutôt à ceci, selon la version de PHP :
/etc/php/8.3/apache2/php.ini
Éditez le fichier correspondant à votre version :
sudo nano /etc/php/8.3/apache2/php.ini
Puis ajustez la directive :
memory_limit = 256M
Rechargez ensuite Apache :
sudo systemctl reload apache2
Si le module Apache ne relit pas correctement la configuration au reload, redémarrez le service :
sudo systemctl restart apache2
Configurer memory_limit avec PHP-FPM
Sur les serveurs modernes, PHP-FPM est très courant, notamment avec nginx ou Apache en proxy FastCGI.
Le fichier principal peut ressembler à ceci :
/etc/php/8.3/fpm/php.ini
Éditez-le :
sudo nano /etc/php/8.3/fpm/php.ini
Réglez la limite mémoire :
memory_limit = 256M
Redémarrez ensuite PHP-FPM :
sudo systemctl restart php8.3-fpmCode language: CSS (css)
Si vous utilisez nginx, rechargez-le aussi si nécessaire :
sudo systemctl reload nginx
Si vous utilisez Apache avec PHP-FPM :
sudo systemctl reload apache2
Définir memory_limit dans un pool PHP-FPM
Pour un réglage par site, il est souvent plus propre de configurer le pool PHP-FPM plutôt que le php.ini global.
Le pool par défaut se trouve souvent ici :
/etc/php/8.3/fpm/pool.d/www.conf
Éditez le pool concerné :
sudo nano /etc/php/8.3/fpm/pool.d/www.conf
Ajoutez ou ajustez :
php_admin_value[memory_limit] = 256M
php_admin_value impose une valeur que le code PHP ne peut pas modifier avec ini_set(). C’est utile si vous voulez fixer une limite stricte par pool.
Si vous voulez laisser le code ou l’application redéfinir la valeur dans certaines limites, utilisez plutôt :
php_value[memory_limit] = 256M
La documentation PHP-FPM montre que les directives PHP peuvent être définies dans la configuration FPM avec php_value, php_flag, php_admin_value et php_admin_flag. Voir la documentation PHP-FPM.
Testez la configuration FPM avant redémarrage :
sudo php-fpm8.3 -tCode language: CSS (css)
Puis redémarrez FPM :
sudo systemctl restart php8.3-fpmCode language: CSS (css)
Configurer memory_limit pour PHP CLI
La CLI utilise souvent un autre fichier :
/etc/php/8.3/cli/php.ini
C’est cette configuration qui concerne les commandes comme :
php script.php;wp plugin update --all;wp media regenerate;composer install;- certains cron lancés en ligne de commande.
Pour vérifier la limite CLI :
php -r 'echo ini_get("memory_limit") . PHP_EOL;'Code language: JavaScript (javascript)
Pour lancer ponctuellement une commande avec une limite différente :
php -d memory_limit=512M script.php
Pour WP-CLI :
php -d memory_limit=512M "$(command -v wp)" media regenerateCode language: JavaScript (javascript)
C’est pratique pour une opération lourde ponctuelle, sans augmenter la limite globale du site web.
Configurer la mémoire WordPress
WordPress possède aussi ses constantes de mémoire. Elles ne peuvent pas dépasser la limite autorisée par PHP, mais elles permettent de demander une limite différente pour WordPress et son administration.
Dans wp-config.php, avant la ligne qui indique d’arrêter l’édition, ajoutez par exemple :
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Code language: JavaScript (javascript)
WP_MEMORY_LIMIT concerne la mémoire côté front et fonctionnement général. WP_MAX_MEMORY_LIMIT concerne les zones d’administration et certaines opérations lourdes.
Attention : si PHP ou PHP-FPM impose memory_limit = 128M, WordPress ne pourra pas magiquement obtenir 512M. Il peut demander plus, mais PHP garde le dernier mot.
Cas legacy : configurer Suhosin memory_limit
Suhosin était une extension de durcissement pour PHP. Elle ajoutait des protections contre certains comportements dangereux ou suspects. Sur de vieux serveurs Debian/PHP 5, elle pouvait être installée par défaut ou ajoutée manuellement.
Le message suivant signifie que Suhosin bloque une tentative d’augmentation de memory_limit au-delà de ce qu’il autorise :
ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value
Sur une configuration PHP 5 legacy, le fichier Suhosin pouvait se trouver ici :
/etc/php5/conf.d/suhosin.ini
ou, selon la distribution :
/etc/php5/mods-available/suhosin.ini
Le réglage ressemblait à ceci :
extension=suhosin.so
[suhosin]
suhosin.memory_limit = 256M
La documentation Suhosin indique que certaines protections peuvent empêcher un script de déclencher ou contourner les limites mémoire PHP, notamment autour de l’exécution et de la profondeur d’appel. Voir la documentation Suhosin.
Après modification, il fallait redémarrer Apache ou PHP-FPM selon le SAPI utilisé :
sudo systemctl restart apache2
ou :
sudo systemctl restart php5-fpm
Sur un serveur moderne, si vous trouvez encore Suhosin, prenez-le comme un signal : l’environnement mérite probablement un audit complet. PHP 5, Apache legacy, extensions anciennes et CMS modernes font rarement un ménage très serein.
Vérifier la valeur effective de memory_limit
Pour vérifier côté CLI :
php -r 'echo ini_get("memory_limit") . PHP_EOL;'Code language: JavaScript (javascript)
Pour vérifier depuis le web, utilisez temporairement :
<?php
echo ini_get( 'memory_limit' );Code language: HTML, XML (xml)
Supprimez ensuite le fichier de test :
rm memory-test.phpCode language: CSS (css)
Dans WordPress, vous pouvez aussi vérifier via :
- Outils > Santé du site > Infos > Serveur ;
- WP-CLI ;
- un plugin de diagnostic ;
- les logs PHP-FPM ou Apache.
Avec WP-CLI :
wp eval 'echo ini_get( "memory_limit" ) . PHP_EOL;'Code language: JavaScript (javascript)
Ne pas confondre memory_limit et mémoire serveur
memory_limit s’applique par processus PHP. Si vous mettez 512M et que PHP-FPM autorise 20 workers, le plafond théorique devient très élevé.
Exemple volontairement simplifié :
512M x 20 workers = 10G de mémoire potentiellement consommable
Donc, avant d’augmenter généreusement memory_limit, vérifiez aussi la configuration PHP-FPM :
grep -E '^(pm|pm\.max_children|pm\.start_servers|pm\.min_spare_servers|pm\.max_spare_servers)' /etc/php/8.3/fpm/pool.d/*.confCode language: JavaScript (javascript)
Une limite mémoire élevée peut être nécessaire pour certains traitements. Mais si elle masque une requête mal optimisée, un plugin gourmand ou une boucle qui charge trop d’objets, vous ne corrigez pas le problème : vous lui achetez simplement un plus grand canapé.
Choisir une valeur raisonnable
Il n’existe pas une valeur universelle. Voici une base pratique :
| Contexte | Valeur de départ | Remarque |
|---|---|---|
| Petit site PHP simple | 128M | Souvent suffisant |
| WordPress classique | 256M | Bon compromis courant |
| WooCommerce | 256M à 512M | Dépend des plugins et imports |
| WP-CLI / imports ponctuels | 512M ou plus | À régler plutôt côté CLI |
| Scripts très lourds | À mesurer | Optimiser avant d’augmenter sans limite |
Évitez memory_limit = -1 en production. Le manuel PHP précise que -1 désactive la limite mémoire. C’est utile pour un test contrôlé, mais rarement judicieux sur un serveur exposé. Voir la documentation PHP.
Solution rapide selon votre stack
Pour Apache avec mod_php :
sudo nano /etc/php/8.3/apache2/php.ini
sudo systemctl reload apache2
Directive à modifier :
memory_limit = 256M
Pour PHP-FPM :
sudo nano /etc/php/8.3/fpm/php.ini
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
Directive à modifier :
memory_limit = 256M
Pour un pool PHP-FPM précis :
sudo nano /etc/php/8.3/fpm/pool.d/www.conf
sudo php-fpm8.3 -t
sudo systemctl restart php8.3-fpm
Directive à ajouter dans le pool :
php_admin_value[memory_limit] = 256M
Pour WordPress :
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );Code language: JavaScript (javascript)
Pour une commande CLI ponctuelle :
php -d memory_limit=512M script.php
Dépannage : la valeur ne change pas
Si la valeur ne change pas après modification, vérifiez dans cet ordre :
- avez-vous modifié le bon fichier
php.inipour le bon SAPI ? - avez-vous redémarré PHP-FPM ou rechargé Apache ?
- un pool FPM impose-t-il
php_admin_value[memory_limit]? - un fichier
.user.inisurcharge-t-il la valeur ? - un panneau d’hébergement impose-t-il une limite supérieure ?
- WordPress tente-t-il de définir une valeur plus haute que PHP ne l’autorise ?
- Suhosin ou une extension legacy bloque-t-elle l’augmentation ?
Pour trouver les fichiers qui mentionnent memory_limit :
sudo grep -RIn 'memory_limit' /etc/php/Code language: JavaScript (javascript)
Sur un ancien serveur PHP 5 :
sudo grep -RIn 'memory_limit\|suhosin.memory_limit' /etc/php5/Code language: JavaScript (javascript)
Résumé rapide
Pour régler correctement une erreur mémoire PHP :
- identifiez le SAPI utilisé : CLI, Apache ou PHP-FPM ;
- trouvez le bon fichier
php.iniavecphpinfo()ouphp --ini; - réglez
memory_limit = 256Mou une valeur adaptée ; - vérifiez les pools PHP-FPM si le site utilise FPM ;
- redémarrez le service PHP concerné ;
- vérifiez la valeur effective côté web et côté CLI ;
- sur un vieux serveur Suhosin, alignez aussi
suhosin.memory_limit.
Le point clé : ne modifiez pas un fichier au hasard. PHP adore avoir plusieurs fichiers de configuration. Et il adore encore plus vous laisser modifier celui qui ne sert à rien.
Conclusion
La directive memory_limit contrôle la mémoire maximale qu’un script PHP peut utiliser. Elle peut être définie globalement dans php.ini, imposée par un pool PHP-FPM, ajustée pour la CLI, ou demandée par WordPress via WP_MEMORY_LIMIT.
Sur un ancien serveur équipé de Suhosin, il fallait aussi configurer suhosin.memory_limit, sinon Suhosin pouvait bloquer les scripts qui tentaient d’augmenter leur limite mémoire.
Sur un serveur moderne, la bonne méthode consiste à identifier le bon contexte PHP, modifier la bonne configuration, redémarrer le bon service, puis vérifier la valeur effective. Simple en théorie. En pratique, c’est surtout une chasse au bon fichier php.ini.
Une fois la limite alignée, les erreurs de mémoire disparaissent. Si elles reviennent, ne vous contentez pas d’augmenter encore la valeur : cherchez aussi le script, la requête ou le plugin qui consomme trop.
Sources utiles
- PHP manual : directive memory_limit
- PHP manual : configuration PHP-FPM
- Suhosin : documentation de configuration
- Octopuce : priorités des directives PHP
Votre site mérite performance et fiabilité. Grâce à mon expérience, je vous aide à optimiser WordPress/WooCommerce pour des résultats visibles.

a beaucoup aidé – la variable n’était pas présente dans le fichier de configuration. Je me suis arraché les cheveux pendant 20min entre le suhosin.ini et le php.ini de /etc/php5/cli/php.ini
bref merci
Je t’en prie reeslo !
Bonjour
Merci pour votre article, je comprend un peu mieux mon problème.
Mais je ne trouve pas la variable dans mon php.ini qui correspond à mon log.
ALERT – configured request variable value length limit exceeded – dropped variable ‘jform[articletext]’ (attacker ‘90.31.35.48’, file ‘/var/www/upmtc/index.php’)
Auriez-vous une idée ?
Cordialement