PHP : configurer memory_limit avec Apache, PHP-FPM, WordPress et Suhosin

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.
Distingo, le livret à 2%

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.ini dans 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 :

ContexteValeur de départRemarque
Petit site PHP simple128MSouvent suffisant
WordPress classique256MBon compromis courant
WooCommerce256M à 512MDépend des plugins et imports
WP-CLI / imports ponctuels512M ou plusÀ régler plutôt côté CLI
Scripts très lourdsÀ mesurerOptimiser 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.ini pour 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.ini surcharge-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 :

  1. identifiez le SAPI utilisé : CLI, Apache ou PHP-FPM ;
  2. trouvez le bon fichier php.ini avec phpinfo() ou php --ini ;
  3. réglez memory_limit = 256M ou une valeur adaptée ;
  4. vérifiez les pools PHP-FPM si le site utilise FPM ;
  5. redémarrez le service PHP concerné ;
  6. vérifiez la valeur effective côté web et côté CLI ;
  7. 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

Votre site mérite performance et fiabilité. Grâce à mon expérience, je vous aide à optimiser WordPress/WooCommerce pour des résultats visibles.

Voyons comment améliorer votre site »

Gravatar for Matt Biscay

Développeur certifié WordPress & WooCommerce chez Codeable, administrateur système et enseignant-chercheur, je mets mon expertise au service de vos projets web.

Ma priorité : des sites performants, fiables et sécurisés, pensés pour offrir la meilleure expérience utilisateur. J’accompagne chaque client avec écoute et pédagogie, pour transformer vos idées en solutions concrètes et durables.

Profitez de solutions WordPress et WooCommerce sur-mesure, pensées pour optimiser durablement votre site.
Explorez les leviers pour booster l’impact de votre site web.

3 pensées sur “PHP : configurer memory_limit avec Apache, PHP-FPM, WordPress et Suhosin”

  1. nano /etc/php5/apache2/php.ini

    On recherche la variable memory_limit et on l’augmente à 256MB

    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

    Reply
  2. 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

    Reply

Opinions