Composer Échec de la mise à jour - mémoire insuffisante
J'ai eu cette erreur lors de l'exécution de composer.phar update sur ma VM:
Erreur fatale PHP: taille de mémoire autorisée de 1073741824 octets épuisée (tentative d'allocation de 144115188075867549 octets) dans phar: ///bin/composer.phar/src/Composer/Util/RemoteFilesystem.php sur la ligne 179
Le composer.json, si besoin:
{
"description" : "The CodeIgniter framework",
"name" : "codeigniter/framework",
"license": "MIT",
"require": {
"php": ">=5.2.4",
"videlalvaro/php-amqplib": "2.5.*"
},
"require-dev": {
"mikey179/vfsStream": "1.1.*",
"videlalvaro/php-amqplib": "2.5.*"
}
}
Le VM récemment récupéré d'un problème de secteur de disque défectueux, et le gars exécutant le VM a dit que le VM has été déplacé vers un nouveau disque. Il n'y a que Java, PHP, httpd, postgre, rabbitmq et le site Web lui-même dans ma machine virtuelle, et il fonctionnait déjà parfaitement pendant environ 4 mois avant que cela ne se produise. J'utilise PHP 5.6.11. Quelqu'un peut-il aider s'il vous plaît?
Résolu en supprimant l'intégralité du dossier du fournisseur, puis en effectuant à nouveau la mise à jour composer, et cela fonctionne ... d'une manière ou d'une autre. Je ne comprends même pas: v
Consultez le wiki Dépannage du compositeur , en particulier la section des erreurs de limite de mémoire.
Par exemple, en exécutant le composer comme ceci:
php -d memory_limit=-1 `which composer` update
Je n'ai plus d'erreur. C'est donc probablement un problème de mémoire insuffisante qui peut être résolu en ligne, sans modifier votre configuration par défaut PHP.
Ce que fait la commande ci-dessus, c'est qu'elle définit la limite de mémoire PHP CLI sur "illimitée" (c'est-à-dire -1), puis exécute la ligne composer update commande.
Veuillez noter qu'au lieu de `quel compositeur` vous devriez probablement utiliser le vrai chemin de votre composer.phar PHP. Le which composer écrit en ligne (comme dans mon exemple ci-dessus) sera résolu en ligne sur votre composer.phar chemin complet (vous pouvez utiliser la forme que vous souhaitez).
La seule chose qui a résolu mon problème était de faire ceci:
/bin/dd if=/dev/zero of=/var/swap.1 bs=1M count=1024
/sbin/mkswap /var/swap.1
/sbin/swapon /var/swap.1
C'est un problème de mémoire, pas un problème de stockage. Vous atteignez votre limite de mémoire PHP.
Modifiez /etc/php.ini et augmentez la limite de mémoire (memory_limit = 128M remplacer par memory_limit = 256M)
Je vous suggère de chercher la raison composer utilise tellement de mémoire et de trouver des moyens de réduire votre utilisation de la mémoire PHP:
- Passez à PHP56 si vous ne l'avez pas déjà fait
- Installez Zend Opcache (partage PHP mémoire entre différentes instances)
- Désinstaller toutes les extensions PECL inutilisées
C'est le problème que vous rencontrez: https://github.com/composer/composer/issues/1898
D'après mon expérience, les erreurs de mémoire de composer signifie généralement qu'il faut trop de mémoire pour rechercher les bonnes combinaisons de packages à installer, en particulier les contraintes de version ne sont pas assez spécifiques. Par exemple, ^ 5.2. 4 correspond à 5.3 à 5.3.29, 5.4 à 5.4.45, etc. Pour chaque version et permutation spécifiques, composer doit obtenir les dépendances du package pour vérifier si toutes les contraintes sont respectées. Ceci est généralement lorsque la consommation de mémoire devient énorme.
Une fois les versions déterminées, la phase d'installation utilise beaucoup moins de mémoire. Les versions résolues de chaque package sont également stockées dans un fichier composer.lock afin que la permutation spécifique installée puisse être répliquée dans d'autres environnements. Et voici la solution potentielle à votre problème: exécutez composer mise à jour dans votre machine de développement (qui devrait avoir suffisamment de mémoire) ), déployez le fichier composer.lock mis à jour et exécutez composer installer sur le serveur.
L'installation de Composer fera toujours référence au composer.lock existant pour les versions à installer pour chaque package, et devrait donc rarement rencontrer des problèmes de mémoire.
Pour une référence sur la façon d'exprimer les contraintes de version dans composer.json, consultez https://getcomposer.org/doc/articles/versions.md
La solution qui fonctionne à la fois sur l'environnement local mais aussi dans un conteneur (par exemple dans une phase de construction d'un pipeline) où composer peut être installé de manière délicate, est
COMPOSER_MEMORY_LIMIT=-1 composer install
Vous pouvez également vous résoudre en supprimant simplement le répertoire du fournisseur et en réexécutant la commande composer install.
php -d memory_limit=-1 /usr/local/bin/composer update --no-scripts
memory_limit=-1 est pour une mémoire illimitée pour ce processus lorsque vous ajoutez php avant le composer pour une mémoire illimitée alors vous devez donner composer chemin complet où son installé sur le serveur) (pour ubntu) son /usr/local/bin/composer La partie Reamining n'est que la mise à jour/l'installation des commandes du compoer
Rien n'a fonctionné pour moi sauf mettre memory_limit = -1 dans php.ini fichier.
cette solution résoudra votre problème.
Mettez à jour votre fichier php.ini puis redémarrez Apache ou votre exemple de serveur: memory_limit = 128M à memory_limit = 1128M
C'est du travail sur moi.
Augmenter le memory_limit valeur sur mon php.ini n'a pas résolu mon problème. Ce que j'ai fait, c'est:
- Supprimer composer.lock,
- exécuter composer update,
Et ça a fait l'affaire!
Essayez d'augmenter la valeur memory_limit dans votre fichier php.ini actif.
; Maximum amount of memory a script may consume (128MB)
; http://php.net/memory-limit
memory_limit = 512M
Par exemple.
php -d memory_limit=-1 /usr/local/bin/composer install
Cette commande fonctionne pour moi.
Dans mon cas, j'étais confronté à cette erreur en raison de l'exécution de composer install à l'intérieur de la boîte vagabonde. L'exécuter à l'intérieur de ma machine hôte n'a pas causé le problème.