« Allowed memory size of 134217728 bytes exhausted » : ce message, affiché en toutes lettres sur une page blanche après l’ajout d’une nouvelle extension, indique une limite de mémoire PHP atteinte, exprimée ici en octets bruts, soit 128 mégaoctets dans cet exemple précis. Le réflexe le plus courant consiste à augmenter la valeur de memory_limit sans chercher plus loin, ce qui fonctionne parfois, mais pas toujours, selon la configuration réelle de l’hébergeur.
Comprendre ce que ce réglage contrôle réellement, et où se situent ses limites côté hébergement, permet d’éviter de tourner en rond sur un incident qui semble résolu en apparence mais qui revient dès qu’une nouvelle extension gourmande est activée.
Ce que memory_limit contrôle exactement
Le réglage memory_limit définit la quantité maximale de mémoire qu’un script PHP individuel peut consommer avant que l’interpréteur n’interrompe son exécution et n’affiche l’erreur fatale correspondante. Ce n’est pas une limite globale du serveur, mais une limite par requête, par processus PHP, ce qui signifie que plusieurs visiteurs simultanés consomment chacun leur propre quota, potentiellement dix fois la valeur définie si dix processus tournent en parallèle.
C’est ce dernier point qui explique pourquoi augmenter memory_limit sans réflexion peut créer un problème différent : sur un pool PHP-FPM avec de nombreux processus actifs simultanément, une valeur trop généreuse par processus peut, cumulée, dépasser la mémoire physique réellement disponible sur le serveur, provoquant cette fois des erreurs déclenchées par l’OOM killer du système plutôt que par PHP lui-même.
Modifier memory_limit correctement
Plusieurs emplacements permettent de modifier ce réglage, avec une priorité qui dépend de la configuration de l’hébergeur :
# wp-config.php, agit uniquement sur le contexte WordPress
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // limite pour l'admin
# php.ini ou fichier .user.ini, agit sur PHP globalement
memory_limit = 256M
La constante WP_MEMORY_LIMIT ne peut jamais dépasser la valeur réellement autorisée par la configuration serveur sous-jacente : c’est un plafond applicatif WordPress, pas une façon de contourner la limite système. Si php.ini impose 128 Mo, définir WP_MEMORY_LIMIT à 512M dans wp-config.php n’aura aucun effet réel.
Pourquoi ça ne marche pas toujours sur un mutualisé
Sur un hébergement mutualisé, certains prestataires plafonnent la mémoire réellement allouable à un compte client, indépendamment de la valeur de memory_limit configurée dans les fichiers du site. Le panneau de contrôle peut afficher une possibilité de configurer memory_limit jusqu’à 512 Mo, tout en appliquant en coulisses une limite de ressources globale au niveau du conteneur ou de la machine virtuelle hébergeant le compte, qui coupe l’exécution avant même que PHP n’atteigne sa propre limite déclarée.
- Vérifier via
phpinfo()la valeur réellement effective dememory_limit, pas seulement celle déclarée dans les fichiers du site - Contacter le support de l’hébergeur pour confirmer l’existence d’un plafond de compte au-delà du réglage PHP visible
- Si le plafond existe et ne peut être relevé, envisager une montée en gamme d’offre plutôt qu’une bataille perdue d’avance sur le réglage
Distinguer limite ponctuelle et fuite mémoire progressive
Une erreur de mémoire qui apparaît systématiquement sur la même action précise (import, génération de rapport) signale un pic ponctuel légitime à dimensionner correctement. Une erreur qui apparaît de façon aléatoire, sur des pages variées, sans lien évident, mérite d’être creusée du côté du code de l’extension plutôt que traitée uniquement par un relèvement de la limite.
Ce second cas ne se résout pas durablement par une augmentation de memory_limit : c’est le signe d’un comportement anormal côté code, comme une boucle qui accumule des données en mémoire sans jamais les libérer, sujet qui relève de l’optimisation du code de l’extension elle-même, pas du réglage serveur.
En résumé
Augmenter memory_limit résout une partie des cas de page blanche liés à un dépassement mémoire, à condition de vérifier que la valeur définie dans wp-config.php correspond bien à ce que le serveur autorise réellement, et non à ce qu’affiche seulement le panneau de contrôle de l’hébergeur. Sur un mutualisé, un plafond de compte invisible peut rendre ce réglage inopérant, ce qui impose de vérifier la valeur effective via phpinfo() avant de conclure que le problème est résolu.
