Повысить максимальную память для composer?
Все равно выдает ошибку:
composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 638590976) (tried to allocate 67108872 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleSet.php on line 84
Fatal error: Out of memory (allocated 638590976) (tried to allocate 67108872 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/RuleSet.php on line 84
mmap() failed: [12] Cannot allocate memory
mmap() failed: [12] Cannot allocate memory
PHP Fatal error: Out of memory (allocated 904929280) (tried to allocate 20480 bytes) in phar:///home/ubuntu/print-press/composer.phar/src/Composer/DependencyResolver/Pool.php on line 205
Fatal error: Out of memory (allocated 904929280) (tried to allocate 20480 bytes) in phar:///home/ubuntu/print-press/composer.phar/src/Composer/DependencyResolver/Pool.php on line 205
Что именно не понятно?
При проблемах с лимитами другое сообщение об ошибке:
Allowed memory size of XXXX bytes exhausted
В вашем же случае, не хватает физической памяти, для того, чтобы отработал composer, который, кстати, кушает её в совершенно не приличных количествах.
Память можно временно нарастить за счёт swap. Проще всего, создать файл нужного объёма, с помощью:
dd if=/dev/zero of=/swapfile bs=1M count=2048
(Получается файл в 2GB забитый нулями, в данном случае.)
Разметить его под свап с помощью:
mkswap /swapfile
И подключить с помощью:
swapon /swapfile
При необходимости, можно его и оставить, добавив нужное в fstab.
Это будет медленнее, но операция завершится успешно.
Также, можно просто добавить памяти, если такая возможность есть.
https://en.wikipedia.org/wiki/Boolean_satisfiabili. explains the SAT problem that products like Composer internally need to handle. Specifically how to handle an unknown number of recursive constraints (every package you include includes other packages with specific constraints) is eventually a brute force problem that boils down to evaluating hundreds of thousands or even millions of possible solutions to the original set of constraints.
The solver needs a ton of RAM and CPU power to do that work, and stores the result of its hard work in the lock file. Using the lock file, any machine you want to deploy to can reproduce the solution by just installing what’s in the lock file. In that scenario Composer barely uses any RAM at all because indeed it’s not doing any hard work internally.
Мне кажется, довольно бесполезно переписываться, не те люди совсем его пишут, судя по тому, что они предлагают и на какие проблемы ссылаются, и каковы результаты. Они отказываются даже задуматься о решении этой проблемы, уже далеко не в первый раз.
Composer update memory limit
I need to run composer update at my hosting so I log in with ssh and try to run the following command inside /www folder where I have Laravel and composer installation:
I’m in contact with my hosting provider, they told me to run the command:
I ran this command but I got: «Could not open file: composer»
What to do? What is the solution here?
20 Answers 20
Set it to use as much memory as it wants with:
Running which composer will tell you where the OS finds the composer executable, and then you simply use the full path in the PHP command:
Note that 512MB might be too few. My perception is that it will happily take 1GB or more, depending on the number of dependencies you use and the variety of versions that you theoretically allow, i.e. if you allow Symfony
Also note that running Composer on the production machine is not the best idea. You would have to have access to Github, maybe provide access credentials, have VCS tools installed, and you will easily break your site if any of the remote hosting servers is offline during your update. It is a better idea to use Composer on a deployment system that does all the preparation, and then moves all the files onto the production server.
Update
My main point remains true: Do not run Composer on machines that have too few memory installed. You potentially need 1.5 GB of free memory to be able to update everything.
Composer: Allowed memory size error when installing package
When I run composer require yab/laravel-scout-mysql-driver this is the output that I get:
I’m running Composer 1.9.2.
My memory limit is 128M. https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors doesn’t seem to provide lot of insight other than to increase my memory limit but it seems like 128M should be sufficient?
It’s weird that the «allowed memory size» is the exact same in every instance. It’s like nothing I’m doing is actually changing the memory size.
3 Answers 3
I got the same issue with same versions (PHP 7.1, Composer 1.9.x) and exactly same memory limit (which after investigation is coded inside/defined in composer).
So, the first thing to do when you encouter this kind of error is to tell composer to not limit the memory with a variable, like this:
COMPOSER_MEMORY_LIMIT=-1 composer require «xxx/yyy»
This is the recommended way but sometime it’s just not work.
So to «fix» it, I do this:
At this point, either you will clearly see a dependency issue, or everything will be installed.
I did this with success 2 times.
Do not delete composer.lock as was recommended in previous answer for projects, which are dunning on the production. Moreover, ensure that it does exist, it helps both to save lots of resources and time on avoid recalculation of dependencies by composer + locking of libraries versions make project behavior more predictable.
From my observations, usually composer requires MOST of the memory exactly to recalculate all the dependencies, find out matching versions for the platform and take a hash from the remote repository and put all this info into the composer.lock. After composer.lock is generated, it does not need too much memory, so that install works perfectly with very limited amount of memory. So sometimes I used a workaround, like (which is quite terrible, and depends on luck, but sometimes worked):
a. run composer require and wait until a new record appears in the composer.lock and then kill the process (to avoid revert of record in composer.lock, which is happens automatically on install failure). If you are lucky you will get it updated before memory limit is reached.
b. then just run composer install and get finally library installed.
Memory limit issue #456
Comments
trunda commented Mar 15, 2012
I have a fresh installation of composer, whenever I run composer.phar install I get error:
I am running MacOs 10.7.3, PHP 5.3.6 (MAMP Pro), Xdebug and composer version 82812eb.
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.
naderman commented Mar 15, 2012
While a 32MB memory limit for CLI is rather low, this is going to be a concern if we want to use composer as a library for a web gui. I don’t see an easy way of lowering memory consumption at the moment. But ideas would be appreciated.
trunda commented Mar 15, 2012
Thanks. I will increase memory limit. But it should be somewhere in documentation imho.
Seldaek commented Mar 15, 2012
I get 25MB of usage here for a normal install. This is indeed a bit high, but we can most likely bring it quite a bit down by using a «compressed» loading mode for the packages that discards all non-solver-relevant data.
ZenVentures commented Jun 1, 2012
For me I had to up PHP memory from 64MB to 128MB to get a Symfony 2 component to install with composer on centOS 5.8, for anyone wondering how much memory you might need for it to work.
stof commented Jun 1, 2012
@ZenVentures the memory consumption is highly variable depending of the dependency graph currently.
ghost commented Jun 13, 2012
I’m getting a similar error:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 78 bytes) in phar:////composer.phar/src/Composer/DependencyResolver/Solver.php on line 169
Note: have the latest update file.
enygma commented Jun 14, 2012
Exact same message here:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 28 bytes) in phar:///path/to/composer.phar/src/Composer/DependencyResolver/RuleSetGenerator.php on line 204
Just ran a «self-update» immediately before it.
Seldaek commented Jun 14, 2012
I modified the bootstrap code so that it now boosts your memory_limit. I realize this is not a long term solution, and we will have to improve on this, but it’ll take some time, so hopefully this is a decent stop-gap measure.
ghost commented Jun 14, 2012
Thanks, it’s working now.
chEbba commented Aug 20, 2012
It was a bad decision to hardcode 512M as a memory_limit. But the real problem is that it requres more than 512Mb of memory. For now packagist has a thons of packages and composer try to put them all in memory (for solving dependencies).
fprochazka commented Aug 20, 2012
The solver might have to be refactored to pull only relevant data. Why does the composer have to download almost 8 thousand packages to memory anyway?
stof commented Aug 20, 2012
@hosiplan because currently, it cannot resolve the dependency without knowing all available packages to build SAT problem, and it cannot know all available packages without loading these metadata
naderman commented Aug 20, 2012
That’s actually not entirely true anymore. The solver itself doesn’t need that anymore. The only place that still reads all packages is the package pool which needs to be able to offer the «whatProvides» method. So memory consumption can probably be reduced by a lot if we throw away the package info there and just keep names and versions and then load the actual data when needed.
fprochazka commented Aug 20, 2012
Is it possible to do it like this?
This will have to go throught all the downloaded jsons and on loading immediately drop everything irelevant to current problem. It might require some invalidation mechanism. Not sure how it works now, but it would be great to go throught only jsons from packagist, that changed.
These caching layers will add complexity, but it should increase the performence, right?
Seldaek commented Aug 20, 2012
I took a first stab at it in #1015. Feel free to try the branch and report if you experience problems.
Troubleshooting#
This is a list of common pitfalls on using Composer, and how to avoid them.
General#
When facing any kind of problems using Composer, be sure to work with the latest version. See self-update for details.
Before asking anyone, run composer diagnose to check for common problems. If it all checks out, proceed to the next steps.
Package not found#
Double-check you don’t have typos in your composer.json or repository branches and tag names.
Be sure to set the right minimum-stability. To get started or be sure this is no issue, set minimum-stability to «dev».
Packages not coming from Packagist should always be defined in the root package (the package depending on all vendors).
If you are updating to a recently published version of a package, be aware that Packagist has a delay of up to 1 minute before new packages are visible to Composer.
Dependencies on the root package#
When your root package depends on a package which ends up depending (directly or indirectly) back on the root package itself, issues can occur in two cases:
During development, if you are on a branch like dev-main and the branch has no branch-alias defined, and the dependency on the root package requires version ^2.0 for example, the dev-main version will not satisfy it. The best solution here is to make sure you first define a branch alias.
Package not found in a Jenkins-build#
Check the «Package not found» item above.
I have a dependency which contains a «repositories» definition in its composer.json, but it seems to be ignored.#
The repositories configuration property is defined as root-only. It is not inherited. You can read more about the reasons behind this in the «why can’t composer load repositories recursively?» article. The simplest work-around to this limitation, is moving or duplicating the repositories definition into your root composer.json.
I have locked a dependency to a specific commit but get unexpected results.#
While Composer supports locking dependencies to a specific commit using the #commit-ref syntax, there are certain caveats that one should take into account. The most important one is documented, but frequently overlooked:
Note: While this is convenient at times, it should not be how you use packages in the long term because it comes with a technical limitation. The composer.json metadata will still be read from the branch name you specify before the hash. Because of that in some cases it will not be a practical workaround, and you should always try to switch to tagged releases as soon as you can.
There is no simple work-around to this limitation. It is therefore strongly recommended that you do not use it.
Need to override a package version#
Let’s say your project depends on package A, which in turn depends on a specific version of package B (say 0.1). But you need a different version of said package B (say 0.11).
You can fix this by aliasing version 0.11 to 0.1:
See aliases for more information.
Memory limit errors#
Composer may sometimes fail on some commands with this message:
PHP Fatal error: Allowed memory size of XXXXXX bytes exhausted
In this case, the PHP memory_limit should be increased.
To get the current memory_limit value, run:
Try increasing the limit in your php.ini file (ex. /etc/php5/cli/php.ini for Debian-like systems):
Composer also respects a memory limit defined by the COMPOSER_MEMORY_LIMIT environment variable:
Or, you can increase the limit with a command-line argument:
This issue can also happen on cPanel instances, when the shell fork bomb protection is activated. For more information, see the documentation of the fork bomb feature on the cPanel site.
Xdebug impact on Composer#
«The system cannot find the path specified» (Windows)#
API rate limit and OAuth tokens#
Because of GitHub’s rate limits on their API it can happen that Composer prompts for authentication asking your username and password so it can go ahead with its work.
If you would prefer not to provide your GitHub credentials to Composer you can manually create a token using the procedure documented here.
Now Composer should install/update without asking for authentication.
proc_open(): fork failed errors#
If composer shows proc_open() fork failed on some commands:
This could be happening because the VPS runs out of memory and has no Swap space enabled.
To enable the swap you can use for example:
You can make a permanent swap file following this tutorial.
proc_open(): failed to open stream errors (Windows)#
If composer shows proc_open(NUL) errors on Windows:
proc_open(NUL): failed to open stream: No such file or directory
This could be happening because you are working in a OneDrive directory and using a version of PHP that does not support the file system semantics of this service. The issue was fixed in PHP 7.2.23 and 7.3.10.
Alternatively it could be because the Windows Null Service is not enabled. For more information, see this issue.
Degraded Mode#
Due to some intermittent issues on Travis and other systems, we introduced a degraded network mode which helps Composer finish successfully but disables a few optimizations. This is enabled automatically when an issue is first detected. If you see this issue sporadically you probably don’t have to worry (a slow or overloaded network can also cause those time outs), but if it appears repeatedly you might want to look at the options below to identify and resolve it.
If you have been pointed to this page, you want to check a few things:
If you are using ESET antivirus, go in «Advanced Settings» and disable «HTTP-scanner» under «web access protection»
If you are using IPv6, try disabling it. If that solves your issues, get in touch with your ISP or server host, the problem is not at the Packagist level but in the routing rules between you and Packagist (i.e. the internet at large). The best way to get these fixed is raise awareness to the network engineers that have the power to fix it. Take a look at the next section for IPv6 workarounds.
If none of the above helped, please report the error.
Operation timed out (IPv6 issues)#
You may run into errors if IPv6 is not configured correctly. A common error is:
We recommend you fix your IPv6 setup. If that is not possible, you can try the following workarounds:
Workaround Linux:
On linux, it seems that running this command helps to make ipv4 traffic have a higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:
Workaround Windows:
On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).
Workaround Mac OS X:
Get name of your network device:
Disable IPv6 on that device (in this case «Wi-Fi»):
You can enable IPv6 again with:
That said, if this fixes your problem, please talk to your ISP about it to try and resolve the routing errors. That’s the best way to get things resolved for everyone.
Composer hangs with SSH ControlMaster#
When you try to install packages from a Git repository and you use the ControlMaster setting for your SSH connection, Composer might hang endlessly and you see a sh process in the defunct state in your process list.
As a workaround, open a SSH connection to your Git host before running Composer:
Zip archives are not unpacked correctly.#
Composer can unpack zipballs using either a system-provided unzip utility or PHP’s native ZipArchive class. The ZipArchive class is preferred on Windows. On other OSes where ZIP files can contain permissions and symlinks, the unzip utility is preferred. You’re advised to install it if you need these features.
Found a typo? Something is wrong in this documentation? Fork and edit it!
Composer and all content on this site are released under the MIT license.