Le WordPress d'aujourd'hui, décodé pour les développeurs

Hébergement & serveurs

« PHP Fatal error: Allowed memory size » côté WP-CLI alors que le site fonctionne normalement

Une commande WP-CLI plante pour épuisement mémoire alors que le site web tourne sans le moindre incident : deux limites PHP bien distinctes en cause.

Par Clément Hadrot • 4 octobre 2024 • 5 min de lecture • Aucun commentaire
« PHP Fatal error: Allowed memory size » côté WP-CLI alors que le site fonctionne normalement

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted : ce message apparaît en pleine exécution d’une commande wp import, alors que le site continue, au même moment, à répondre normalement aux visiteurs sur le même serveur. Le réflexe naturel consiste à soupçonner une fuite mémoire introduite par une extension récente. Le plus souvent, la cause est plus simple et plus structurelle : WP-CLI et le serveur web ne partagent pas forcément la même limite mémoire, ni même le même fichier de configuration PHP.

Comprendre pourquoi ce fatal survient uniquement en ligne de commande demande de revenir sur une distinction souvent ignorée : PHP dispose de plusieurs SAPI (interfaces d’exécution), chacune pouvant charger sa propre configuration.

Symptôme : un fatal en CLI, un site parfaitement stable en HTTP

Le symptôme se manifeste presque toujours de la même façon : une commande WP-CLI qui traite un volume important de données, comme un import de contenu, une régénération de miniatures ou une recherche-remplacement sur l’ensemble de la base, s’arrête net avec un message d’épuisement mémoire. Pendant ce temps, les pages du site continuent de s’afficher sans ralentissement perceptible, et aucune erreur n’apparaît dans les journaux de PHP-FPM lié au serveur web.

Cette dissociation totale entre le comportement web et le comportement CLI est le signal qui oriente vers une différence de configuration entre les deux SAPI, plutôt que vers un problème de code affectant l’ensemble du site.

Diagnostic : deux SAPI, deux fichiers php.ini, deux limites

L'essentiel à retenir : WP-CLI utilise le SAPI cli, pas php-fpm ; Le php.ini de la CLI est souvent un fichier distinct ; Une commande volumineuse peut demander plus de mémoire qu'une requête web

PHP-FPM, qui traite les requêtes du serveur web, et le SAPI cli, utilisé par WP-CLI depuis le terminal, chargent chacun leur propre fichier php.ini, situés à des emplacements distincts sur la plupart des distributions Linux. La commande suivante révèle lequel WP-CLI utilise réellement :

wp cli info

Sa sortie inclut une ligne php_bin et un chemin vers le fichier php.ini effectivement chargé, qui diffère fréquemment de celui utilisé par PHP-FPM, visible par ailleurs via une page exposant phpinfo(). Une commande complémentaire confirme précisément la valeur active pour la limite mémoire du côté CLI :

wp eval 'echo ini_get( "memory_limit" );'

Il n’est pas rare de découvrir ainsi une limite mémoire de 128 Mo côté CLI contre 512 Mo côté PHP-FPM, alors que les deux services tournent sur la même version de PHP et le même serveur.

Correctif : relever la limite mémoire spécifiquement pour le SAPI CLI

Une fois le fichier php.ini de la CLI identifié, la valeur de memory_limit s’y ajuste directement, sans impact sur la configuration de PHP-FPM ni sur les autres sites hébergés sur la même machine :

memory_limit = 512M

Lorsque la modification directe du fichier n’est pas possible, notamment sur un hébergement mutualisé où seul un fichier .user.ini reste accessible, WP-CLI accepte également une valeur passée en argument de commande, utile pour un besoin ponctuel sans modifier durablement la configuration :

wp import export.xml --authors=skip --extra-info=1 \
  --skip-plugins --skip-themes \
  --context=cli \
  --allow-root 2>&1 | tee import.log

Une alternative plus directe consiste à surcharger temporairement la valeur via la variable d’environnement reconnue par PHP lui-même :

PHP_MEMORY_LIMIT=512M wp import export.xml

Pourquoi une commande CLI demande souvent plus de mémoire qu’une requête web

Une requête HTTP classique traite en général un nombre limité d’objets en mémoire : un article, ses métadonnées, quelques requêtes de contexte. Une commande WP-CLI comme un import de contenu ou une réindexation manipule au contraire des lots de données bien plus larges en une seule exécution, ce qui explique pourquoi la limite mémoire nécessaire côté CLI dépasse fréquemment celle qui suffit largement au bon fonctionnement du site en navigation normale.

Prévention : distinguer clairement CLI et pool PHP-FPM dans la documentation du parc

  • Noter, pour chaque serveur du parc, l’emplacement exact du php.ini utilisé par WP-CLI, distinct de celui du pool web.
  • Fixer une limite mémoire CLI volontairement plus haute que celle du pool PHP-FPM, en anticipation des opérations d’import ou de maintenance.
  • Ne jamais aligner aveuglément les deux limites sur une même valeur : le réglage mémoire du pool PHP-FPM répond à une logique de densité de processus concurrents, absente en ligne de commande où une seule commande s’exécute à la fois.

Un fatal en CLI qui n’apparaît jamais côté web n’indique pas un site fragile : il indique deux configurations distinctes qu’on a oublié d’aligner.

En résumé

Le SAPI cli utilisé par WP-CLI charge, sur la plupart des serveurs, un fichier php.ini différent de celui de PHP-FPM, avec sa propre valeur de memory_limit. Vérifier ces deux fichiers distincts avant de soupçonner une fuite mémoire applicative évite bien des diagnostics inutiles, et un ajustement ciblé de la limite CLI suffit, dans l’immense majorité des cas, à faire disparaître ce fatal sans toucher au réglage du pool PHP-FPM qui sert le site.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi