Composer:安装包时允许内存大小错误

neu*_*ert 5 php composer-php

当我运行时,composer require yab/laravel-scout-mysql-driver这是我得到的输出:

Using version ^2.40 for yab/laravel-scout-mysql-driver
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.3.2/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.3.2/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.
Run Code Online (Sandbox Code Playgroud)

我正在运行 Composer 1.9.2。

这是我使用 -vvv 时输出的最后几行:

Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-ircmaxell$password-compat.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-paragonie$constant-time-encoding.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-yab$laravel-scout-mysql-driver.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-symfony$class-loader.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-symfony$polyfill-apcu.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-symfony$polyfill-xml.json from cache
Reading /Users/redacted/.composer/cache/repo/https---repo.packagist.org/provider-gecko-packages$gecko-php-unit.json from cache
PHP Fatal error:  Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.3.2/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/Cellar/composer/1.3.2/libexec/composer.phar/src/Composer/DependencyResolver/RuleWatchGraph.php on line 52

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.
Run Code Online (Sandbox Code Playgroud)

我的内存限制是 128M。https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors除了增加我的内存限制之外似乎没有提供很多见解,但似乎 128M 应该足够了?

php -d memory_limit=-1 /usr/local/bin/composer require yab/laravel-scout-mysql-driver没有帮助 - 我收到了“允许的内存大小为 1610612736 字节用尽”错误。与memory_limit=1024M.

我做了php --ini并从中得到了/usr/local/etc/php/7.1/php.ini,我编辑它以将内存限制更改为 1024MB 并得到相同的结果:“允许的内存大小为 1610612736 字节已用完”。

奇怪的是,“允许的内存大小”在每个实例中都完全相同。就像我所做的实际上没有改变内存大小。

有任何想法吗?

Céd*_*ric 5

(可能是)Composer 更新重复失败——内存不足

我在相同的版本(PHP 7.1,Composer 1.9.x)和完全相同的内存限制(经过调查后在 Composer 中编码/定义)中遇到了同样的问题。

当你遇到这种错误时,首先要做的就是告诉 Composer 不要用变量限制内存,如下所示:

COMPOSER_MEMORY_LIMIT=-1 composer require "xxx/yyy"

这是推荐的方法,但有时它不起作用。

在我的项目中,每次我执行 .lock 操作时,composer.lock 似乎都会损坏composer require xxx

为了“修复”它,我这样做:

  • 删除您的vendor文件夹 ( rm -fr vendor)
  • 消除composer.lockrm composer.lock
  • 确保您composer.json包含新的要求(由于之前的要求,它应该存在composer require),如果没有,请添加它
  • 做一个新鲜的composer install

此时,要么您将清楚地看到依赖关系问题,要么所有内容都将被安装。


小智 5

不要按照之前项目答案中的建议删除composer.lock,这些项目在生产中催款。此外,确保它确实存在,它有助于节省大量资源和时间,避免通过作曲家重新计算依赖项+锁定库版本,使项目行为更加可预测。

“composer.lock”是任何项目都必须有的,它的删除有点类似于composer update所有项目。您可能会因为解锁而遇到麻烦,并因此将较新版本的库提取到项目中并进行重大更改。在大多数情况下,composer.json 中的库版本并不太严格(人们通常会放主要版本,最好情况下放次要版本,几乎从不放补丁版本),因此删除大型项目的composer.lock 可能会导致对于巨大的问题,它并没有真正的帮助,因为composer必须获取所有可能的分支和所有必需库的版本,这些库是在composer.json中定义的,只是为了生成composer.lock。

您的解决方案php -d memory_limit=-1 /usr/local/bin/composer require yab/laravel-scout-mysql-driver是正确的,并且在大多数情况下都有效。在我看来,问题是你的可用内存有限。在这种情况下,您可以尝试执行以下操作之一:

  1. 如果您位于 OSX env 中的 docker 容器内,请在那里重新配置您的虚拟机(检查 docker 的首选项,您可以增加可以由 docker 分配的内存和 CPU 量 - 这是一个非常流行的问题:人们忘记了这一点在 OSX 中,有一个虚拟机正在运行来为 docker 提供服务,因此它们默认在 CPU/MEM/磁盘分配方面受到限制)
  2. 如果 OSX 上的 docker 不是这种情况,并且主机对可用内存有真正的限制,那么理想情况下使用开发环境,它要么有更多内存,要么为此添加交换区。
  3. 根据我的观察,composer 通常需要大部分内存来重新计算所有依赖项、找出平台的匹配版本并从远程存储库获取哈希值并将所有这些信息放入composer.lock 中。生成composer.lock后,它不需要太多内存,因此安装在非常有限的内存下可以完美运行。所以有时我会使用一种解决方法,例如(这非常糟糕,并且取决于运气,但有时有效):

    A。运行composer require并等待,直到composer.lock中出现新记录,然后终止该进程(以避免恢复composer.lock中的记录,这会在安装失败时自动发生)。如果幸运的话,您将在达到内存限制之前更新它。

    b. 然后运行composer install并最终安装库。

如果这些方法都不起作用,您可以尝试在composer.lock中手动添加记录,并使用适当的哈希值。在这种情况下,您可以避免重新计算所有依赖项并中间跳转到安装过程。但这只是一个快速的胜利,稍后您将再次面临同样的问题(下次您需要重新计算锁定文件时)。