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/vagrant/vagrantfiles/Vagrantfile#L6

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

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)

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