Hello everybody. I am looking for assistance as my poor, befuddled brain is cannot handle many more Magento issues this side of Christmas.
I’m trying to update an extension within M2 using the Module Manager. It tries to update the extension and fails with this:
Updating dependencies (including require-dev)
Package operations: 0 installs, 24 updates, 0 removals
- Updating symfony/service-contracts (v1.1.7 => v1.1.8): The following exception is caused by a lack of memory or swap, or not having swap configured
Check https://getcomposer.org/doc/articles/troubleshooting.md#proc-open-fork-failed-errors for details
In Process.php line 337:
proc_open(): fork failed - Cannot allocate memory
I’ve contacted Cloudways who are hosting the site, and they recommend I scale up the package from 4GB RAM to 8GB RAM. This does however increase the cost p/m from $42 to $80. Is this necessary though? The site is still in development, but whilst browsing it, it is not slow in anyway, so not struggling for resources. Is there another option?
4GB is more than enough to perform this operation so long as you don’t have a dozen other Memory hungry applications running in the background.
Did you check your root
.htaccess file? By default the configuration bottlenecks PHP
memory_limit usage to 756MB. Even when you change the appropriate value, the file resets after each Upgrade. Ref: Web Setup Wizard cannot pass: "Check Component Dependency"
Thanks Craig, however PHP memory_limit was already set at 2G?
Try bumping it up to 3 or 4GB as you have it to spare.
It’s also worth mentioning that Updating/Upgrading via the CLI is less resource intensive.
Thanks Craig. Funnily enough I do normally use the CLI for updating plugins, however with the one in question composer was not finding an update, even though one was. In the end I contacted the plugin developer, who found that composer was locked at an old version and gave me a different composer command to use, so all good now
I’ve ignored Cloudways advice, as the 4GB package we are on is adequate for our needs.
Right, so I have run in to this problem again. I’m trying to update an extension using the CLI and composer. The extension requires that its dependencies are updated as well. Here is the error when running the update command:
./composer.json has been updated
Loading composer repositorUpdating dependencies (including require-dev)
mmap ()failed:  Cannot allocate memory
mmap ()failed:  Cannot allocate memory
PHP Fatal error: Out of memory (allocated 1484791808) (tried to allocate 4096 bytes) in phar:///usr/local/bin/Composer/DependencyResolver/RuleWatchGraph.php on line 52
In .htaccess in the php7 section I am using:
php_value memory_limit 2G
php_value max_execution_time 18000
Monitoring server usage, RAM usage is 2.4 GB out of 4GB whilst CPU usage is 3-4%.
Am I going to upgrade the server package or is there another option?
I’d be interested to see your PHP Configuration readout. You can get this by creating a file in your Magento Root Directory, which will give you a readout. Check this post for instructions on how to do this (PHP Troubleshooting (How to find important information)). The results may highlight something useful.
It’s also worth creating a support ticket to Cloudways and ask if they will setup a 512MB or 1024MB swap file for you. This “buffer” can often assist in low PHP environments by sacrificing some disk space to act as additional memory. It’s a 2 minute job that might save you the upgrade costs.
What I can’t wrap my head around though, is that all of my Dev Servers (and the Sandbox server I use for creating videos) are all running on 2GB RAM - So, you shouldn’t have any issues there. Having said that, I just remembered that Cloudways servers also might be running Varnish, ElasticSearch and other services that’s eating into your 4GB.
Thanks for your response. I’ve sent you a direct message with a link to the file. Let me know once you’ve viewed it so I can delete it.
We do have ElasticSearch and Varnish enabled on the server. I’ve been looking in to this issue further, particularly a swap file, so I will contact Cloudways and see if they will do it.
I had a look at the report… The only item that really stands out to me is:
I’m not saying that this is the issue, but I would have expected these values to say
4096M to take advantage of the 4GB Memory that your setup has. It might be worth asking why this value is lower than the server specification that you’re using.
So, with your 4GB server you potentially have 2 PHP
- First one set by the Server Environment (as indicated in the phpinfo file)
- And the second in the
This might be completely normal to see on a Cloudways Server and I might be barking up the wrong tree. But it stood out to me so I figured I’d mention it.
Aside from that, the issue might just come down to what I mentioned before - In that 4GB is simply being eaten up by other services running in the background.
Sorry that I couldn’t narrow this down any further.
Thanks Craig for taking a look, it’s much appreciated. The 2GB bottleneck is strange, but can be changed easily within the customer’s dashboard to 4GB, refreshing the phpinfo file confirms it. I will contact Cloudways and see if they will set up a swap file, otherwise I’m going to have to bite the bullet and upgrade the package. Within our Magento I’ve set up varnish cache, installed Mirasvit’s ElasticSearch extension, installed a full page cache warmer and a onestepcheckout, all of which I know use more memory, so in some ways the extra RAM will at least ensure there aren’t any further bottlenecks.
I had this same problem on cloudways with a different application. I had plenty of memory but composer kept failing with a proc error.
I updated to php 7.3 and restarted apache and ran composer update again, no issue.
Not super tech savvy so not sure why that worked. I wanted to leave an option for people still looking for a fix.
I’ve dealt with this quite a bit on cloudways. I have 2GB limits set, which I think is fine. You will run in to issues like this and I have even tried increasing to max (4gb) and it still didn’t change anything.
COMPOSER_MEMORY_LIMIT=-1 composer require
php -d memory_limit=-1 bin/magento
I’ve also had this not work and if you restart all the services on your server and then try again it usually will free up enough mem in combination with using the above commands. I think ultimately though, I will be bumping to the $80 plan as it should resolve all of this. The last thing you want it to run out of mem or have some sort of erratic issues due to low mem when your store is actually live.
On a couple of occasions, I found that I had to assign a temporary swap file: Magento install Composer #5 install error. Even despite increasing PHP Values.