我昨天尝试使用Composer在我的一个Laravel 4项目上安装aws/aws-sdk-php
,我不记得确切的事件链但是没有成功安装。从那以后,我一直收到Composer内存耗尽的错误 - Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 32 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52
。
我将php.ini memory_limit
增加到-1,这仍然在我的开发和生产环境(生产是Cent OS 6)中发生。如果我在运行memory_limit
时通过CLI增加composer_update
,则安装成功完成但需要一段时间。
是否需要清除某种缓存以防止Composer耗尽内存?我觉得每次运行composer update时它仍在尝试安装AWS SDK。
作曲家文件
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"require": {
"laravel/framework": "4.0.*",
"rtablada/package-installer": "dev-master",
"mogreet/mogreet-php": "dev-master",
"twilio/laratwilio": "dev-master",
"balloon/elephant.io": "dev-master",
"facebook/php-sdk": "dev-master",
"way/generators": "dev-master",
"codesleeve/asset-pipeline": "dev-master",
"natxet/CssMin": "dev-master"
},
"autoload": {
"classmap": [
"app/commands",
"app/controllers",
"app/models",
"app/database/migrations",
"app/database/seeds",
"app/tests/TestCase.php",
"app/libraries"
]
},
"scripts": {
"post-install-cmd": [
"php artisan optimize"
],
"pre-update-cmd": [
"php artisan clear-compiled"
],
"post-update-cmd": [
"php artisan optimize"
],
"post-create-project-cmd": [
"php artisan key:generate"
]
},
"config": {
"preferred-install": "dist"
},
"minimum-stability": "dev"
}
答案 0 :(得分:20)
编辑:在继续前行之前,请确保您运行的是最新版本的作曲家,您可以通过composer self-update
运行composer update
时,它将为每个库(或最新版本)计算最新的gitref,然后将安装该版本的库。然后,它会将这些版本存储在composer.lock
文件中。
当您运行composer install
时,它只会安装composer.lock
文件中定义的版本。
composer update
花费这么长时间并占用大量内存的原因是因为它必须跟踪每个库的版本,将其与您在composer.json
中定义的版本进行比较,然后检查所有库的依赖。这是一个非常密集的过程。
我发现使用hhvm
运行作曲家(您可以安装here)会大大加快composer update
进程的速度。
除此之外,您只需要使用高内存使用量并将其增加到php.ini
文件中。确保更新与CLI相关的那个。
编辑:您永远不应该在生产环境中运行composer update
。您应该只在开发时更新依赖项,然后在生产环境中使用composer install
安装上次使用的一组编写器依赖项。
答案 1 :(得分:15)
目前,Composer上存在一个错误,导致内存耗尽。
如果你这样做
composer install
然后删除供应商内的文件夹
rm -rf vendor/laravel
并做
composer update
你会收到这个错误。这是一个错误,它不应该耗尽内存。
现在你可以通过以下方式自行修复:
php -d memory_limit=-1 /usr/local/bin/composer update
另外,请检查this thread,他们即将修复此问题。
答案 2 :(得分:13)
试试这个。它解决了我的问题。我想更好的方法来修复它而不是更新内存。
sudo composer self-update
答案 3 :(得分:3)
简单,输入以下命令:
rm -rf vendor/
rm -rf composer.lock
php composer install --prefer-dist
应该适用于低内存机器或其他内存问题
答案 4 :(得分:3)
我也遇到了这个问题,但是我使用interface Theme1 extends Theme {
a: {
b: {
c: CustomType;
}
}
}
。
brew
仍然无法解决我的composer --version
brew info composer
brew upgrade composer
...
==> Upgrading 1 outdated package:
composer 1.9.0 -> 1.9.2
==> Upgrading composer
...
使用其他人提到的php内存限制最终解决了这个问题。
composer require drupal/environment_indicator
答案 5 :(得分:2)
它占用如此多内存的原因是因为处理包和替换关键字时Composer的行为。
替换背后的想法是它允许你做两件事:
用您自己的版本替换标准库版本。例如如果你在'symfony / yaml'中找到一个例子,你可以将它分叉,修复bug然后将其作为名为“nightmicu / yaml”的包发布。然后你可以告诉作曲家“nightmicu / yaml”取代“symfony / yaml”。然后通过“nightmicu / yaml”来满足您安装的任何其他依赖于“symfony / yaml”的包。
它允许人们将包作为单个组件发布,以及完整的库,例如symfony框架包替换了它的每个组件包。
问题是,大约1小时前,replace关键字在整个Packagist中全局工作。
这意味着对于已经分叉和重命名的流行库,需要安装大量可能的版本。这就是导致大量内存使用并且需要很长时间才能处理的原因。
如果你得到最新版本的composer.phar,它现在应该会更好,因为'replace'现在的工作方式不同,只需要处理根composer.json中命名的包,即你必须明确地使用你的包composer.json让它可以替换或作为替代,但我自己无法测试它。
答案 6 :(得分:1)
在Windows上解决此问题的最简单方法是:
转到:C:\ ProgramData \ ComposerSetup \ bin
修改 composer.bat
将其更改为:
@ECHO OFF
php -d memory_limit=-1 "%~dp0composer.phar" %*
保存文件并运行:
composer selfupdate
答案 7 :(得分:1)
如果您有8 GB或更高的内存,则可以确定将PHP memory_limit增加到1 GB或512MB。在Mac上打开终端-
php --ini
php-memory-limits.ini
文件。nano /usr/local/etc/php/7.4/conf.d/php-memory-limits.ini
memory_limit = 1G
php -r "echo ini_get('memory_limit').PHP_EOL;"
brew services restart php
完成。增加内存限制也会减少composer update
完成时间,这很好。
如果您想加快composer update
的时间。尝试安装流行的Prestissimo软件包。
答案 8 :(得分:0)
仅在您的版本为1. *时才尝试执行此代码:
composer self-update --2
我遇到很多问题,然后我给了 memory_limit:10G 。之后,我遇到了同样的问题,那么我尝试更新作曲家的版本,然后就解决了。 您可以检查编译器版本
composer --version
答案 9 :(得分:0)