Mémoire PHP épuisée dans WordPress : diagnostiquer avant d’augmenter

Le message « Allowed memory size exhausted » indique qu’une allocation a dépassé la limite mémoire appliquée à l’exécution PHP. Il ne dit pas pourquoi la consommation a augmenté. Avant de relever ce plafond, identifiez l’action, la configuration active et le volume traité. Une limite plus haute peut aider un traitement légitime, mais elle ne corrige pas une boucle ou un chargement sans fin.

Confirmer l’erreur et le contexte qui l’a déclenchée

Conservez le message complet, l’heure, le fichier et la ligne, puis notez l’action en cours : consultation, import, génération d’image ou tâche planifiée. La ligne signale l’allocation refusée ; la consommation peut avoir commencé plus tôt dans le traitement. Un simple statut 500 ne prouve pas un épuisement mémoire. Le diagnostic de l’erreur 500 WordPress permet de retrouver la couche concernée si le message reste imprécis.

Rapprochez la demande des journaux PHP et des traces WordPress disponibles. Les détails doivent rester dans un emplacement protégé, sans exposition publique de chemins ou de données. Un journal incomplet ou une ligne isolée ne suffit pas à désigner l’extension responsable. Recherchez également le changement récent qui pourrait expliquer le nouveau volume ou la répétition d’une opération.

Reproduisez sur une copie de test avec un jeu de données borné et représentatif. Gardez les paramètres utiles : nombre d’éléments, taille des images, options de l’import et état du cache. Ne relancez pas un gros traitement en production simplement pour obtenir une seconde erreur. Vérifiez d’abord s’il a déjà créé ou modifié des données, afin d’éviter un doublon au prochain essai.

Relever la limite réellement utilisée par PHP

La directive memory_limit encadre la mémoire que le script peut allouer. Relevez sa valeur effective dans le contexte en échec, avec la version PHP. Une valeur écrite dans un fichier ne prouve pas qu’il est chargé ou qu’elle reste active ensuite. Le PHP du terminal, celui du serveur web et celui d’une tâche peuvent utiliser des configurations différentes.

WordPress intervient aussi lors de son initialisation des constantes mémoire. WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT ne sont pas deux réserves de RAM ajoutées au serveur. Ils participent aux limites demandées dans différents contextes, sous les contraintes de PHP et de l’hébergement. Consultez la configuration réellement appliquée après l’initialisation plutôt que de recopier une valeur trouvée sur un autre site.

La fonction wp_raise_memory_limit() ne garantit pas qu’une hausse demandée sera possible. Certains réglages ne sont pas modifiables dans ce contexte. Un plafond système supplémentaire comme max_memory_limit peut également intervenir lorsque la version PHP le prend en charge. Faites identifier le réglage qui bloque effectivement la demande ; modifier plusieurs fichiers sans ce repère rend le résultat difficile à vérifier.

Mesurer le pic sans le confondre avec la RAM du serveur

Dans un environnement de diagnostic maîtrisé, memory_get_peak_usage() aide à relever le pic suivi par PHP pendant l’exécution. Notez la valeur, le moment du relevé et l’option utilisée. Un relevé trop tôt dans le traitement ou après une autre requête ne décrit pas forcément l’action fautive. Comparez des essais portant sur les mêmes données et le même parcours.

La documentation de memory_get_usage() distingue les allocations suivies par PHP et la mémoire réservée par son gestionnaire. Même avec l’option de mesure réelle, ce n’est pas toute la mémoire physique du processus : certaines allocations natives d’extensions peuvent échapper à ce relevé. Complétez les mesures avec celles du système quand le processus ou le serveur manque de mémoire.

Ces chiffres doivent servir une hypothèse précise. Comparez un petit lot et le volume attendu, puis observez où la consommation progresse. Une hausse continue à chaque itération peut orienter vers des objets conservés ou un traitement qui recharge inutilement les mêmes données. Elle ne prouve pas seule une fuite mémoire. Gardez le résultat complet et les conditions du test, y compris les essais moins favorables.

Réduire la demande avant de déplacer le plafond

Pour un import ou un export, vérifiez si les données peuvent être traitées par lots plutôt que chargées entièrement. Chaque étape doit conserver un résultat vérifiable et permettre une reprise cohérente. Réduire la taille d’un lot ne suffit pas si les objets précédents restent accumulés en mémoire. Contrôlez aussi les requêtes qui ramènent tous les résultats alors qu’une sélection limitée répond au besoin.

Pour les images, prenez en compte les dimensions et le travail de décodage ou de transformation. Le poids du fichier compressé ne décrit pas la mémoire nécessaire à son traitement. Une extension d’image peut aussi utiliser des ressources natives. Réduisez les opérations inutiles et testez la bibliothèque réellement utilisée, sans conclure que le même fichier aura le même coût dans tous les environnements.

Si l’origine reste incertaine, le diagnostic de performance WordPress aide à organiser les mesures et les hypothèses. Isolez un composant ou une opération sur la copie de test, puis comparez dans les mêmes conditions. Évitez la désactivation générale des extensions et les changements simultanés de PHP, de thème et de cache, qui empêchent de relier le résultat à une correction.

Ajuster un budget compatible avec l’hébergement

Une hausse peut être justifiée si le traitement est utile, borné et correctement conçu. Avant une modification de production, vérifiez une sauvegarde récente et restaurable ainsi qu’une copie de la configuration précédente. Documentez la valeur active, celle proposée et le motif. Choisissez un ajustement mesuré avec une marge adaptée au volume attendu ; une valeur universelle copiée ailleurs ne constitue pas un dimensionnement.

Appliquez le changement dans la configuration effectivement utilisée, selon la procédure de l’hébergeur. Si un fichier PHP doit être modifié, contrôlez sa syntaxe et son chargement ; le guide des erreurs de syntaxe PHP détaille ces vérifications. Ne désactivez pas toute limite pour faire disparaître l’avertissement. Après application, relisez la valeur effective au lieu de vous fier uniquement au succès de l’enregistrement.

La capacité globale doit aussi être vérifiée. Avec PHP-FPM et ses workers, plusieurs requêtes peuvent s’exécuter en parallèle. Leur mémoire observée s’ajoute aux besoins des autres services et du système. La seule multiplication du nombre de workers par la limite PHP ne décrit pas toute cette consommation. Faites confirmer le budget et la simultanéité acceptables avant une hausse sur un hébergement partagé.

Valider le traitement complet et conserver le retour

Rejouez l’action sur le volume prévu et vérifiez qu’elle se termine avec le résultat attendu. Pour un import, contrôlez le nombre d’éléments et l’absence de doublons ; pour une transformation, vérifiez les fichiers produits. Les essais d’écriture doivent rester dans un environnement ou un cas autorisé. Un écran de succès ne remplace pas le contrôle des données réellement créées ou modifiées.

Comparez le pic, la durée et les journaux après correction. Vérifiez également les parcours concernés en visite déconnectée, sur mobile et sans JavaScript lorsque leur contenu doit rester accessible. Une erreur 502/503 ou un processus tué peut relever d’un autre problème de ressources : rapprochez alors les traces système et serveur. Ne transformez pas chaque panne ultérieure en une nouvelle augmentation de la limite mémoire.

Conservez les mesures avant et après, le réglage retenu et le moyen de revenir en arrière. Une évolution du volume ou du nombre de tâches simultanées peut demander une nouvelle évaluation. Si le budget ou le composant responsable reste difficile à établir, un accompagnement WordPress peut partir de ces éléments vérifiés. Le résultat recherché est un traitement soutenable, pas seulement une erreur repoussée à une charge plus élevée.