Another possibility, unless that is your only dev server, is to never run UPDATE there. Always run composer update on dev, test it to check if nothing is broken and commit/push the composer.lock file. Then on the live server you run
my droplets run on 512MB and encountered the same issue. after creating swaps it never occurs again. Since i works on multiple droplets, I end up save the script into Forge's recipes so I can easily create swaps for new droplets.
Enabling Swap before installing with composer might be the way to go - I've had to do it on Vaprobash since the VM's have limited amounts of RAM available. Enabling swap lets the system fall back to use hard drive space for extra RAM when RAM is completely used.
(It's slower, but it means composer and other installers won't fail!)
@mikebronner's response may have worked because logging in and running the commands I believe may be different than running the commands from an automated script, altho I'm not 100% sure on how/why that seems to be.
If it is a production server, I still strongly recommend to use the method I said above (commit composer.lock and use composer install). If it's dev, the best way would be giving it a bit more ram (usually 1gb is enough), else swap does just fine (I've used 364mb ram with 1gb swap without any problems).
@fideloper the reason for the high memory usage is composer calculating all the dependencies. When he deleted the vendor folder, composer didn't have to take current version into consideration, so it just check remote version and end up using less ram. Still, sooner or later (depending on the amount of dependencies), it will run out of memory even deleting the vendor folder.
Maybe this issue should be reported as a Composer bug - they might be able to add some memory checking, and optimise the memory usage to keep it under the limit.
That said, for a product server - definitely commit composer.lock, and only run composer install --no-dev. It avoids no end of dependency hell pain...
@Valorin when I first got this problem, I ended up at the composer issue track at github, this is a knowing issue and they had plans to work on it and by that time they had already get some improvements somewhere (if I recall correctly) but, (again if I recall correctly) it would be hard to have bigger improvements because of how the structure was set, so it would need some rewrites on this and it would be planned for a future major update. This is what I remember from memory of some months ago and since so much time passed and lots of people have this issue I can't seem to find it :( But from what I see they are always suggesting to increase ram (or swap) and no signal of it changing to use less memory :/
I know this thread is a little old however since I had a similar issue recently I thought I'd put in some additional information. While the solution posted by mikebronner works on occasion, it will still sometimes fail. Without upgrading to a server with more RAM, the solution is to enable SWAP as indicated by fideloper. While he did link the commands you can find a detailed tutorial specifically from Digital Ocean.
I am having the same problem with Composer and Memory Limit. Reading through DO guide, there is the following note. Will this be a problem when using @sitesense receipt?
Although swap is generally recommended for systems utilizing traditional spinning hard drives, using swap with SSDs can cause issues with hardware degradation over time. Due to this consideration, we do not recommend enabling swap on DigitalOcean or any other provider that utilizes SSD storage. Doing so can impact the reliability of the underlying hardware for you and your neighbors.
If you need to improve the performance of your server, we recommend upgrading your Droplet. This will lead to better results in general and will decrease the likelihood of contributing to hardware issues that can affect your service.