Support the ongoing development of Laravel.io →
Installation Configuration
Last updated 2 years ago.
0

Self answering...

Turns out I can temporarily up the memory to limitless when I run composer update, although surely there's a deeper issue here. It's using 535Mb if I run composer with the profiler flag enabled

php -d memory_limit=-1 /usr/local/bin/composer update --verbose --profile
Last updated 2 years ago.
0

I don't have this specific problem. Rather, I've had the problem of composer runs returning "Killed" because my vagrant box didn't have enough RAM. So, I up them from 512 to 768 and it works ok.

https://github.com/ShawnMcCool/vagrant-chef/blob/master/vagran...

Last updated 2 years ago.
0

Hi, i have found the solution for this a month ago. It is very simple and it has a lot to do on how composer is used when deploying for production.

On your local machine where you have 4+GB RAM, you run command composer update. To your git code you include composer.lock file. Just delete it from .gitignore in your root directory of your project and stage the file. Commit your code to your production server and there you need to run composer install.

It is a lot quicker and uses 90% less RAM to complete.

Seldaek commented a month ago @judgej I guess you are just at the edge of your server's memory so it gets killed or not depending on the amount of > ram used when you start composer. Anyway you should avoid running update on servers at all, rather commit the > > composer.lock file and run install on servers, which uses very little memory.

Source: https://github.com/composer/composer/issues/1898

Last updated 2 years ago.
0

Just stumbled onto your answer @mabasic. Don't know why I havent thought about this before, but it definitely is the most relevant answer. Not only does it solve the problem, but it also kind of points out that what most of us should be doing (some of us, depending on the dev / staging environments, don't actually want to composer-update on deployment, just install what's missing on the other side and regenerate autoload files)

Last updated 2 years ago.
0

Your solution works for me.

I tried disabling xdebug and yet it didn't work. Seems in my case xdebug was nothing to be blamed of but the php memory itself.

I can afford slowness since composer is not getting updated that often. My dev team uses xdebug so it was good it was not the cause.

Thanks,

duellsy said:

Self answering...

Turns out I can temporarily up the memory to limitless when I run composer update, although surely there's a deeper issue here. It's using 535Mb if I run composer with the profiler flag enabled

php -d memory_limit=-1 /usr/local/bin/composer update --verbose --profile
0

Sign in to participate in this thread!

Eventy

Your banner here too?

duellsy duellsy Joined 4 Feb 2014

Moderators

We'd like to thank these amazing companies for supporting us

Your logo here?

Laravel.io

The Laravel portal for problem solving, knowledge sharing and community building.

© 2024 Laravel.io - All rights reserved.