Erreurs de mémoire et de temps d'exécution dans PrestaShop : memory_limit et compagnie

Vous lancez une importation de produits et elle s'arrête au milieu sur une page blanche. Une tâche planifiée qui synchronise le stock ne se termine plus depuis des semaines. L'export des commandes fonctionne pour un mois, mais pas pour une année. Dans le journal d'erreurs apparaissent des messages comme Allowed memory size of ... bytes exhausted ou Maximum execution time of ... seconds exceeded.

Ce sont les deux limites de PHP les plus courantes, et il y en a plus qu'on ne le croit. Voyons lesquelles, où elles se configurent et quand il est judicieux de les augmenter.

Les limites en jeu

memory_limit

La mémoire maximale qu'un processus PHP peut utiliser. Si la requête la dépasse, PHP l'interrompt avec une erreur fatale : Allowed memory size exhausted. Dans la boutique, cela se traduit par une page blanche ou une erreur 500.

max_execution_time

Le temps maximal, en secondes, pendant lequel un script peut s'exécuter. Au-delà, PHP l'arrête : Maximum execution time exceeded. Attention : sous Linux, ce compteur n'inclut pas le temps que le script passe à attendre la base de données ou une API externe, seulement son propre temps d'exécution.

Celles qui sont en dehors de PHP

Même si PHP n'a rien interrompu, la requête peut mourir plus tôt pour une autre raison :

• Le gestionnaire de processus PHP (PHP-FPM) a son propre temps maximal par requête.
• Le serveur web ou le proxy (Apache, Nginx, un répartiteur de charge ou un CDN) ferme la connexion s'il ne reçoit pas de réponse dans un certain délai. Le client voit une erreur 502 ou 504, alors que le script continue peut-être de s'exécuter derrière.
• La base de données peut couper les connexions inactives ou les requêtes trop longues.
• max_input_vars, qui ne concerne ni la mémoire ni le temps mais produit des symptômes semblables : il limite le nombre de champs qu'accepte un formulaire. Une fiche produit avec beaucoup de déclinaisons ou un écran de traductions peut n'enregistrer qu'une partie des données sans afficher la moindre erreur.

Où elles se configurent

Cela dépend de l'hébergement :

• Dans le panneau de l'hébergeur, dans la section de configuration de PHP : c'est le cas le plus courant.
• Dans un fichier php.ini ou .user.ini à la racine du site, si l'hébergeur le permet.
• Dans la configuration du serveur, si vous avez un VPS ou un serveur dédié.

Pour savoir quelles valeurs la boutique a réellement, ne vous fiez pas à ce qu'indique le panneau : vérifiez-les dans les informations serveur du back-office (Paramètres avancés → Informations) ou avec une page temporaire affichant la configuration de PHP, que vous supprimerez ensuite.

Où elles apparaissent dans PrestaShop

• Importations CSV volumineuses, surtout avec des images téléchargées depuis une URL pendant l'importation.
• Régénération des miniatures sur des catalogues avec beaucoup de photos ou des photos très grandes.
• Tâches planifiées de modules qui se synchronisent avec un ERP, un fournisseur ou une marketplace.
• Exports de commandes, de clients ou de produits sur de longues périodes.
• Génération de PDF avec de nombreuses factures à la fois.
• Vider le cache ou recompiler le conteneur Symfony dans PrestaShop 8 et 9, ce qui demande beaucoup de mémoire d'un coup.
• Des pages précises : une catégorie de milliers de produits sans pagination, un produit avec des centaines de déclinaisons, une fiche commande avec de nombreuses lignes.

Quand augmenter la limite et quand s'en abstenir

Augmenter memory_limit ou max_execution_time est raisonnable lorsque le processus est légitimement lourd et ponctuel : une importation initiale, une migration, une régénération complète. PrestaShop exige déjà par lui-même une mémoire minimale généreuse, et beaucoup d'hébergements sont livrés avec des valeurs inférieures à ce dont la boutique a besoin.

Mais s'il vous en faut toujours plus, le problème est ailleurs :

• Un processus qui charge tout en mémoire (tous les produits, toutes les commandes) au lieu de travailler par lots. Avec le catalogue d'aujourd'hui, cela passe ; avec celui de l'an prochain, non.
• Une boucle qui ne se termine pas ou qui traite la même chose encore et encore, à cause d'un bug du module.
• Des requêtes sans index sur des tables qui ont grossi, de plus en plus lentes.
• Des appels lents à des API externes dans le même processus, un par produit.

Si une limite énorme « répare » une page normale de la boutique, comme une catégorie ou une fiche produit, rien n'est réparé : cette page consomme des ressources qu'elle ne devrait pas, et sous le trafic, elle fera tomber le serveur.

Comment poser le diagnostic

1. Lisez le message complet dans le journal d'erreurs PHP : il indique le fichier et la ligne où la mémoire ou le temps a été épuisé. Parfois, c'est la ligne d'un module précis ; d'autres fois, une fonction du cœur appelée depuis un module.
2. Distinguez web et terminal : la panne survient-elle en appelant une URL ou en lançant un script en console ? Chacun a ses limites.
3. Regardez le code de réponse : une erreur 500 vient généralement de PHP ; une 502 ou 504, du serveur web ou du proxy lassé d'attendre.
4. Reproduisez-la sur une copie, en activant le mode debug de PrestaShop, qui affiche l'erreur à l'écran au lieu d'une page blanche.
5. Vérifiez si elle augmente avec les données : si cela échoue sur un an et pas sur un mois, le processus ne travaille pas par lots.

Bonnes pratiques pour les processus longs

• Lancez les tâches lourdes depuis le terminal, et non en appelant une URL, chaque fois que le module le permet.
• Découpez les grosses importations en fichiers plus petits.
• Planifiez les tâches lourdes en dehors des heures de trafic et évitez que deux d'entre elles se chevauchent.
• Utilisez des modules qui travaillent par lots et reprennent là où ils s'étaient arrêtés en cas d'interruption.
• Maintenez PrestaShop, PHP et les modules à jour : les versions récentes de PHP consomment moins de mémoire et sont plus rapides avec le même code.

Comment le résoudre dans PrestaShop

RKR Sentinel vous alerte sur Telegram quand la boutique rencontre des erreurs de mémoire épuisée, des délais dépassés, des erreurs fatales ou des réponses 500, avec le message, le fichier et la ligne, un extrait du code, la trace, l'URL et les versions, sans devoir activer le mode debug en production. Chaque erreur est regroupée selon son empreinte pour que les répétitions n'inondent pas votre conversation. Si le problème vient d'un processus qu'il faut réécrire pour qu'il travaille par lots, ou de limites du serveur dont vous ne savez pas où elles se configurent, nous le diagnostiquons sur une copie et le corrigeons avec un forfait d'heures de support Rekire.