Limite de mémoire PrestaShop dépassée : Causes et solutions

Comprendre le memory_limit de PHP

La directive memory_limit dans PHP contrôle la quantité de RAM qu'un seul processus PHP peut consommer avant que le moteur ne le termine avec une erreur fatale. Lorsque vous voyez le message "Allowed memory size of X bytes exhausted" dans PrestaShop, cela signifie qu'une requête PHP spécifique a tenté d'utiliser plus de mémoire que la limite configurée ne l'autorise.

Chaque chargement de page dans PrestaShop exécute du code PHP qui charge le framework, se connecte à la base de données, traite les données, effectue le rendu des templates et envoie le HTML au navigateur. Chacune de ces étapes consomme de la mémoire. Le memory_limit agit comme un filet de sécurité : il empêche un processus incontrôlé de consommer toute la RAM disponible du serveur, ce qui ferait planter les autres processus et pourrait potentiellement faire tomber l'ensemble du serveur.

Le memory_limit par défaut dans PHP est généralement de 128M (128 mégaoctets). PrestaShop recommande officiellement au moins 256M, et de nombreuses boutiques nécessitent 512M ou plus selon la taille du catalogue, les modules installés et le trafic. Comprendre ce qui génère la consommation de mémoire vous aide à déterminer la bonne valeur pour votre boutique plutôt que d'augmenter aveuglément la limite.

Comment vérifier votre limite de mémoire actuelle

Il existe plusieurs façons de vérifier quelle limite de mémoire votre installation PrestaShop utilise actuellement.

Depuis le Back Office PrestaShop

Naviguez vers Paramètres avancés > Informations. Cette page affiche la configuration PHP de votre serveur, y compris la valeur actuelle du memory_limit. PrestaShop affichera également des avertissements si la valeur est inférieure au minimum recommandé.

En utilisant phpinfo()

Créez un fichier temporaire appelé info.php dans le répertoire racine de votre PrestaShop avec ce contenu :

<?php phpinfo(); ?>

Accédez-y via votre navigateur à l'adresse votredomaine.com/info.php. Recherchez « memory_limit » dans la page pour voir à la fois la Valeur locale (celle qui est réellement active) et la Valeur maître (celle qui est définie dans php.ini). La valeur locale peut différer de la valeur maître si un .htaccess, un .user.ini ou l'application elle-même la surcharge.

Important : Supprimez ce fichier immédiatement après vérification. Une page phpinfo() expose des informations détaillées sur la configuration du serveur que les attaquants peuvent exploiter.

Via la ligne de commande

Si vous avez un accès SSH, exécutez :

php -i | grep memory_limit

Notez que la configuration PHP en ligne de commande peut différer de la configuration du serveur web. Pour vérifier la valeur côté web, utilisez la méthode phpinfo() ou le back office PrestaShop.

Causes courantes des erreurs de limite de mémoire

Imports de produits volumineux

L'importation de produits via CSV est l'une des opérations les plus gourmandes en mémoire dans PrestaShop. Chaque ligne du fichier d'importation est chargée en mémoire, traitée, validée et insérée dans la base de données. Un fichier CSV contenant 10 000 produits, chacun avec de multiples déclinaisons, images et descriptions, peut facilement nécessiter 512 Mo ou plus de mémoire.

L'outil d'importation de PrestaShop traite les produits par lots, mais la taille des lots et la quantité de données par produit déterminent l'empreinte mémoire totale. Les champs de texte volumineux (descriptions avec HTML), les nombreuses colonnes et les fichiers encodés en UTF-8 avec des caractères spéciaux augmentent tous l'utilisation de mémoire par ligne.

Pour réduire la consommation de mémoire lors des importations :

• Découpez les fichiers CSV volumineux en morceaux plus petits (1 000 à 2 000 lignes chacun)
• Importez d'abord les produits sans images, puis importez les images séparément
• Désactivez les modules non essentiels pendant l'importation (statistiques, indexation de recherche)
• Utilisez l'importation en ligne de commande si disponible, ce qui évite les limites de timeout du serveur web

Produits avec de nombreuses déclinaisons

Les produits avec de nombreux attributs (taille, couleur, matière) génèrent des déclinaisons de manière exponentielle. Un produit avec 5 tailles, 10 couleurs et 3 matières crée 150 déclinaisons. Chaque déclinaison est un enregistrement de base de données séparé avec son propre prix, référence, stock et associations d'images. Lorsque PrestaShop charge une page produit pour l'édition dans le back office, il charge toutes les déclinaisons en mémoire en une seule fois.

Les produits avec plus de 500 déclinaisons sont un point de friction connu. Au-delà de 1 000 déclinaisons, vous atteindrez presque certainement les limites de mémoire avec la configuration par défaut. Les solutions incluent :

• Augmenter le memory_limit à 512M ou 1G pour le back office
• Restructurer les produits pour réduire le nombre de déclinaisons (produits séparés au lieu de méga-déclinaisons)
• Utiliser des modules qui gèrent les déclinaisons plus efficacement grâce à la pagination

Modules surchargés ou mal codés

Les modules tiers sont une source fréquente de problèmes de mémoire. Les problèmes courants incluent :

• Chargement de tables de base de données entières dans des tableaux PHP : Un module qui exécute SELECT * FROM ps_orders sans clause LIMIT charge chaque commande jamais passée en mémoire. Pour une boutique avec 100 000 commandes, cela peut consommer des centaines de mégaoctets.
• Fuites de mémoire dans les boucles : Des modules qui traitent des éléments dans une boucle mais accumulent des objets sans les libérer. Le ramasse-miettes de PHP gère les cas simples, mais les références circulaires et les références stockées peuvent empêcher le nettoyage.
• Journalisation excessive : La journalisation de débogage qui écrit de grands tableaux ou objets dans les fichiers de log, en utilisant var_export() ou print_r() sur des objets PrestaShop complexes, peut consommer des quantités énormes de mémoire.
• Traitement d'images non optimisé : Les modules qui redimensionnent ou ajoutent des filigranes aux images en utilisant GD ou ImageMagick chargent l'intégralité de l'image non compressée en mémoire. Une image de 5000x5000 pixels en couleur 24 bits nécessite environ 75 Mo de RAM juste pour les données de pixels.

Pour identifier quel module cause des problèmes de mémoire, vérifiez attentivement le message d'erreur. Il inclut généralement un chemin de fichier qui pointe vers le module responsable. Vous pouvez également activer le mode débogage de PrestaShop pour obtenir des traces de pile plus détaillées.

Catalogues volumineux et requêtes complexes

Les boutiques avec des dizaines de milliers de produits, de nombreuses catégories et des structures d'attributs complexes exercent plus de pression sur la mémoire pendant le fonctionnement normal. Les pages de catégories avec navigation à facettes (recherche par filtres) sont particulièrement exigeantes car le moteur de filtrage doit calculer les valeurs d'attributs disponibles à travers des milliers de produits.

Les pages de listing des produits, commandes et clients du back office chargent toutes des données en mémoire pour l'affichage. Avec de très grands jeux de données, même la vue de liste basique peut atteindre les limites de mémoire, surtout quand des modules ajoutent des colonnes ou des calculs supplémentaires à ces listes.

Compilation des templates Smarty

PrestaShop utilise le moteur de templates Smarty, qui compile les templates en fichiers PHP pour un rendu plus rapide. Le processus de compilation lui-même consomme de la mémoire, et les templates complexes avec de nombreuses inclusions, boucles et blocs conditionnels nécessitent plus de mémoire à compiler. Après la première compilation, les versions en cache sont utilisées, ce problème se pose donc principalement lorsque le cache est vidé ou pendant le développement.

Comment augmenter la limite de mémoire

Méthode 1 : php.ini

La méthode la plus fiable consiste à modifier directement le fichier de configuration PHP. L'emplacement dépend de votre configuration :

• Debian/Ubuntu : /etc/php/8.x/fpm/php.ini (PHP-FPM) ou /etc/php/8.x/apache2/php.ini (mod_php)
• CentOS/RHEL : /etc/php.ini ou /etc/php.d/
• cPanel : Éditeur INI MultiPHP dans WHM ou cPanel

Trouvez la ligne memory_limit et modifiez-la :

memory_limit = 512M

Après la sauvegarde, redémarrez PHP-FPM ou Apache :

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache avec mod_php
sudo systemctl restart apache2

Méthode 2 : .htaccess (Apache avec mod_php uniquement)

Ajoutez cette ligne au fichier .htaccess dans le répertoire racine de votre PrestaShop :

php_value memory_limit 512M

Cette méthode ne fonctionne qu'avec Apache utilisant mod_php. Si vous utilisez PHP-FPM (ce qui est plus courant sur les configurations modernes), cette directive est silencieusement ignorée ou peut provoquer une erreur 500. Pour vérifier quel gestionnaire PHP vous utilisez, regardez la ligne Server API dans la sortie de votre phpinfo().

Méthode 3 : .user.ini (PHP-FPM)

Créez ou éditez un fichier appelé .user.ini dans le répertoire racine de votre PrestaShop :

memory_limit = 512M

PHP-FPM lit les fichiers .user.ini depuis la racine du document. Notez que les modifications prennent effet après la période user_ini.cache_ttl (300 secondes / 5 minutes par défaut), vous devrez donc peut-être attendre ou redémarrer PHP-FPM pour que le changement prenne effet immédiatement.

Méthode 4 : Dans le code de PrestaShop

PrestaShop définit sa propre limite de mémoire dans le fichier config/defines.inc.php. Cherchez une ligne comme :

@ini_set('memory_limit', '256M');

Vous pouvez augmenter cette valeur directement dans le code. Cependant, cette approche a une limitation : la fonction ini_set() ne peut augmenter la limite de mémoire que jusqu'à la valeur définie dans php.ini. Si php.ini définit memory_limit = 128M et que votre code essaie de le mettre à 512M, la limite réelle restera 128M (sauf si la valeur maître autorise les surcharges, ce qui dépend de la classification PHP_INI_ALL vs PHP_INI_SYSTEM).

Méthode 5 : Configuration par pool (PHP-FPM)

Si vous gérez votre propre serveur, vous pouvez définir les limites de mémoire par pool PHP-FPM. Éditez le fichier de configuration du pool (par ex., /etc/php/8.2/fpm/pool.d/www.conf) et ajoutez :

php_admin_value[memory_limit] = 512M

Utiliser php_admin_value rend ce paramètre immuable — il ne peut pas être surchargé par .user.ini ou ini_set(). C'est utile pour imposer des limites dans les environnements multi-locataires.

Mémoire par processus vs mémoire partagée

Il est important de comprendre que memory_limit s'applique à chaque processus PHP individuel, pas à PHP dans son ensemble. Si vous définissez memory_limit = 512M et que votre serveur exécute 20 processus PHP simultanés, la consommation de mémoire maximale théorique par PHP est de 10 Go (20 x 512 Mo).

C'est pourquoi augmenter aveuglément la limite de mémoire peut causer des problèmes. Sur un serveur avec 4 Go de RAM, définir memory_limit = 1G avec 10 workers PHP-FPM signifie que PHP seul pourrait essayer d'utiliser 10 Go, provoquant un swap intensif du système ou déclenchant le OOM killer de Linux, qui termine de force les processus pour libérer de la mémoire.

L'approche correcte consiste à équilibrer la limite de mémoire avec le nombre de workers PHP :

• RAM disponible pour PHP = RAM totale - overhead OS - mémoire MySQL - mémoire serveur web - autres services
• Workers PHP max = RAM disponible pour PHP / memory_limit

Par exemple, sur un VPS de 4 Go : 4 Go total - 0,5 Go OS - 1 Go MySQL - 0,25 Go Nginx = 2,25 Go pour PHP. Avec memory_limit = 256M, vous pouvez exécuter en toute sécurité 8-9 workers PHP-FPM. Avec memory_limit = 512M, vous ne pouvez exécuter que 4 workers, ce qui signifie que moins de requêtes simultanées peuvent être servies.

Configurez le pool PHP-FPM en conséquence :

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Diagnostiquer les fuites de mémoire et la consommation excessive

Si augmenter la limite de mémoire ne fait que retarder l'erreur plutôt que la corriger, vous avez probablement une fuite de mémoire ou un processus inefficace. Voici comment diagnostiquer la cause fondamentale.

Activer le mode débogage PrestaShop

Éditez config/defines.inc.php et définissez :

define('_PS_MODE_DEV_', true);

Cela active le rapport d'erreurs détaillé, y compris le fichier exact et le numéro de ligne où la limite de mémoire a été dépassée. La trace de pile montre la chaîne d'appels de fonctions qui a mené à l'erreur, vous aidant à identifier le module ou la fonction du noyau responsable.

Surveiller l'utilisation de la mémoire dans le code

Vous pouvez ajouter un suivi de la mémoire à des sections de code spécifiques pour identifier précisément où les pics de mémoire se produisent :

error_log('Mémoire avant opération : ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... opération ...
error_log('Mémoire après opération : ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Pic d\'utilisation mémoire : ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

La fonction memory_get_usage(true) retourne la quantité réelle de mémoire allouée par le système d'exploitation à PHP, tandis que memory_get_peak_usage(true) retourne la quantité maximale allouée à n'importe quel moment pendant la requête.

Utiliser le profilage Xdebug

Le profileur de Xdebug génère des rapports détaillés des appels de fonctions, du temps d'exécution et de la consommation de mémoire. Activez-le temporairement dans votre configuration PHP :

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Ouvrez les fichiers cachegrind générés dans un outil comme KCacheGrind ou Webgrind pour visualiser quelles fonctions consomment le plus de mémoire. C'est l'approche diagnostique la plus approfondie mais elle ne devrait être utilisée que sur les serveurs de développement en raison de l'impact significatif sur les performances.

Vérifier les requêtes lentes et MySQL

Parfois, ce qui semble être un problème de mémoire PHP est en réalité un problème MySQL. Une requête lente qui retourne des millions de lignes obligera PHP à allouer de la mémoire pour l'ensemble du jeu de résultats. Vérifiez le journal des requêtes lentes de MySQL :

sudo tail -100 /var/log/mysql/slow-query.log

Si vous voyez des requêtes avec de grands jeux de résultats, ajoutez des clauses LIMIT appropriées ou implémentez la pagination dans le module responsable.

Mémoire OPcache

OPcache est une extension PHP qui met en cache le bytecode PHP compilé dans la mémoire partagée, éliminant le besoin d'analyser et de compiler les fichiers PHP à chaque requête. OPcache a sa propre allocation mémoire, séparée du memory_limit.

La mémoire OPcache par défaut (opcache.memory_consumption) est de 128 Mo. PrestaShop avec plusieurs modules installés peut facilement dépasser cette limite. Lorsque OPcache manque de mémoire, il commence à évincer les entrées en cache et à recompiler les fichiers à chaque requête, provoquant une dégradation significative des performances.

Vérifiez l'état d'OPcache depuis la ligne de commande :

php -r "print_r(opcache_get_status());"

Ou consultez la section opcache dans la sortie de votre phpinfo(). Valeurs clés à surveiller :

• opcache.memory_consumption : Mémoire totale allouée pour OPcache (augmentez à 256M pour PrestaShop)
• opcache.max_accelerated_files : Nombre maximum de fichiers qu'OPcache peut mettre en cache (augmentez à 20000 pour PrestaShop)
• Mémoire utilisée vs mémoire libre : Si la mémoire libre est proche de zéro, augmentez memory_consumption
• Taux de succès du cache : Devrait être au-dessus de 99 %. En dessous de 95 % indique une pression mémoire ou une invalidation fréquente du cache

Configuration OPcache recommandée pour PrestaShop :

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Notez que la mémoire OPcache est partagée entre tous les processus PHP, contrairement au memory_limit qui est par processus. Augmenter la mémoire OPcache ne se multiplie pas par le nombre de workers.

Configuration mémoire MySQL

MySQL a sa propre configuration mémoire qui affecte indirectement les performances de PrestaShop et peut contribuer à la pression mémoire globale du serveur. Les paramètres mémoire clés de MySQL incluent :

• innodb_buffer_pool_size : Le principal tampon mémoire pour les tables InnoDB. Réglez-le à 50-70 % de la RAM disponible sur un serveur de base de données dédié, ou 25-50 % sur un serveur partagé exécutant à la fois PHP et MySQL. C'est le paramètre de performance MySQL le plus important.
• sort_buffer_size et join_buffer_size : Tampons par connexion pour le tri et les jointures. Gardez-les aux valeurs par défaut sauf si vous avez des requêtes lentes spécifiques qui bénéficient de tampons plus grands. Les régler trop haut gaspille de la mémoire car ils sont alloués par connexion.
• query_cache_size : Déprécié dans MySQL 8.0 et supprimé entièrement. Si vous êtes encore sur MySQL 5.7, un petit cache de requêtes (64M) peut aider, mais les grands caches de requêtes provoquent de la contention et réduisent les performances.

Si MySQL consomme trop de mémoire, il en reste moins pour PHP, vous forçant potentiellement à réduire les workers PHP-FPM ou la limite de mémoire. Utilisez mysqladmin status ou SHOW GLOBAL STATUS pour surveiller la consommation mémoire de MySQL.

Quand mettre à niveau votre hébergement

Parfois, augmenter la limite de mémoire et optimiser votre code ne suffit pas. Voici les signes indiquant que vous avez besoin d'un serveur plus puissant :

• Vous fonctionnez constamment à la limite de mémoire maximale : Si vos processus utilisent régulièrement plus de 90 % de la mémoire allouée, même après optimisation, vous avez besoin de plus de RAM.
• Le serveur swappe fréquemment : Vérifiez avec free -h ou vmstat 1. Si l'utilisation du swap est constamment élevée, vous n'avez pas assez de RAM physique.
• Réduire les workers PHP nuit aux performances : Si vous avez dû réduire les workers PHP-FPM à 3-4 pour accommoder la limite de mémoire, votre site ne peut pas gérer efficacement les visiteurs simultanés.
• Votre catalogue ne cesse de croître : Une boutique qui fonctionnait bien avec 1 000 produits peut avoir des difficultés avec 10 000. Les besoins en mémoire évoluent avec la taille du catalogue, notamment pour l'indexation de la recherche, les listings de catégories et les opérations du back office.
• Vous avez besoin d'un memory_limit supérieur à 1G : Si un seul processus PHP nécessite plus de 1 Go de mémoire pour des opérations normales (pas des importations), quelque chose est fondamentalement défaillant soit dans votre code, soit dans la capacité de votre hébergement. Investiguez la cause fondamentale avant d'augmenter simplement la limite davantage.

Lors de la mise à niveau, privilégiez plus de RAM plutôt que plus de cœurs CPU pour PrestaShop. Un serveur avec 8 Go de RAM et 2 cœurs servira PrestaShop mieux qu'un serveur avec 4 Go de RAM et 4 cœurs. Envisagez également de séparer MySQL sur son propre serveur ou d'utiliser un service de base de données géré, ce qui libère entièrement la RAM du serveur d'application pour PHP.

Référence rapide : Paramètres recommandés par taille de boutique

Les recommandations suivantes servent de points de départ. Surveillez votre utilisation réelle et ajustez en conséquence.

• Petite boutique (moins de 1 000 produits, peu de modules) : memory_limit = 256M, 2 Go de RAM, 4-6 workers PHP
• Boutique moyenne (1 000 à 10 000 produits, 20+ modules) : memory_limit = 512M, 4 Go de RAM, 6-8 workers PHP
• Grande boutique (10 000+ produits, nombreuses déclinaisons) : memory_limit = 512M-1G, 8 Go+ de RAM, 8-16 workers PHP, serveur de base de données séparé
• Pendant les importations : Augmentez temporairement à 1G ou 2G, puis restaurez la valeur normale

Rappelez-vous que la limite de mémoire est un plafond de sécurité, pas un objectif. Une boutique PrestaShop bien optimisée devrait rarement utiliser plus de 128-256 Mo par requête pour les chargements de page normaux. Si les opérations normales nécessitent systématiquement 512 Mo ou plus, investiguez et corrigez la cause sous-jacente plutôt que de continuer à augmenter la limite.