Closed septentrio closed 8 years ago
Not much we can do about this. Try raising the minimum stability to stable in the settings to decrease the amount of candidates.
81 MB is just not enough for complex composer tasks...
@discordier Setting Minimum stability to "Stable" seems to work. Thanks
Well, that works, But there is no fun at all.
On a machine with 1GB I get the following notice:
I have seen those a lot in the last week. I wonder why the memory usage of composer exploded from then on.
Seems to be some kind of recursion.
Internally, everything is only linked by reference in composer. Therefore this should not be that much of an issue. What does composer say when you run from console and enable profiling?
Here we go (line 200ff.) 20160215-composer-log.txt
Interesting, apparently the versions from symfony/cache
let the usage explode from 346.9MB to 797.0MB
Even if the cache is empty ...
Switching to stable releases cures the pain only for a short while.
Could you share your composer.json with me?
Of course:
{
"name": "local/website",
"description": "A local website project",
"type": "project",
"license": "proprietary",
"require": {
"bugbuster/banner": ">=3.5.4.0,<3.6-dev",
"contao-community-alliance/composer-client": ">=0.16.2.0,<0.17-dev",
"contao-legacy/easyupdate3": "3.3.2.9008",
"contao-legacy/hc_mailchimp": "3.0.1.6006-RC",
"contao-legacy/newsarticle": "3.2.0.9004",
"leounglaub/contao-header-code": "3.0.3.0",
"madeyourday/contao-rocksolid-antispam": "1.0.4.0",
"madeyourday/contao-rocksolid-columns": "1.0.7.0",
"madeyourday/contao-rocksolid-custom-elements": "1.3.9.0",
"madeyourday/contao-rocksolid-frontend-helper": "1.2.3.0",
"madeyourday/contao-rocksolid-icon-picker": "1.0.8.0",
"madeyourday/contao-rocksolid-mega-menu": "1.1.6.0",
"madeyourday/contao-rocksolid-slider": "1.5.7.0",
"madeyourday/contao-rocksolid-theme-assistant": ">=1.1.7.0,<1.2-dev",
"menatwork/currentinstallation": ">=1.2.0.0,<1.3-dev",
"menatwork/synccto": ">=3.2.0.0-beta1,<3.3-dev@beta",
"metamodels/bundle_all": ">=2.0.0.0,<2.1-dev",
"netzmacht/contao-leaflet-maps": "dev-develop",
"netzmacht/php-leaflet": "0.7.3.x-dev",
"psi/redirect4ward": ">=2.1.1.0,<2.2-dev",
"webgriffe/pdftotext-bundle": ">=1.0.0.0,<1.1-dev"
},
"prefer-stable": false,
"minimum-stability": "stable",
"config": {
"preferred-install": "dist",
"cache-dir": "cache",
"component-dir": "../assets/components",
"discard-changes": true
},
"repositories": [
{
"type": "composer",
"url": "https://legacy-packages-via.contao-community-alliance.org/"
},
{
"type": "artifact",
"url": "packages"
},
{
"type": "composer",
"url": "http://legacy-packages-via.contao-community-alliance.org/"
}
],
"extra": {
"contao": {
"migrated": "done",
"version-locks": {
"metamodels/core": ">=2.0.0.0-alpha9,<2.1-dev@alpha",
"madeyourday/contao-rocksolid-antispam": ">=1.0.4.0,<1.1-dev",
"contao-legacy/easyupdate3": ">=3.3.2.9008,<3.4-dev",
"contao-legacy/hc_mailchimp": ">=3.0.1.6006-RC,<3.1-dev@RC",
"contao-legacy/newsarticle": ">=3.2.0.9004,<3.3-dev",
"leounglaub/contao-header-code": ">=3.0.3.0,<3.1-dev",
"madeyourday/contao-rocksolid-columns": ">=1.0.7.0,<1.1-dev",
"madeyourday/contao-rocksolid-custom-elements": ">=1.3.9.0,<1.4-dev",
"madeyourday/contao-rocksolid-frontend-helper": ">=1.2.3.0,<1.3-dev",
"madeyourday/contao-rocksolid-icon-picker": ">=1.0.8.0,<1.1-dev",
"madeyourday/contao-rocksolid-mega-menu": ">=1.1.6.0,<1.2-dev",
"madeyourday/contao-rocksolid-slider": ">=1.5.7.0,<1.6-dev",
"codefog/contao-news_categories": ">=2.7.0.0,<2.8-dev"
}
}
}
}
In this case, I tried to lock some extensions, but this doesn't help, too..
It seems that there are some workarounds, BUT ...
As @Toflar stated in https://community.contao.org/de/showthread.php?61319-Composer-m%F6chte-1-GB-RAM-haben&p=399460&viewfull=1#post399460 (and some discussions at the Composer issue tracker gave some hints into the same direction), the problem seems to be that Composer tries to track down an enormous amount of dependencies during the update process.
So, in short, we only have the possibility to delimit the amount of versions being checked by setting more granular version requests in Contao itself and in Contao extensions, too. For example, there is no need to check _all _symfony packages but only certain ones which we need.
I'm not shure if it would be better to create a ticket @ contao/core.
Any other opinions?
It's not a problem of Contao either. It's just a logical question of dependency constraints. I think we should simply try to track down the source of this memory explosion in composer and then do a proper issue report there and see what happens when the PHP community drops in.
Which is exactly what I am and have been doing so far. Sadly this is hard to track down.
We can not reduce the memory from within the plugin. This will however be worked around by the new cloud resolver by @Toflar.
Fancy :)
I don't know wether if it's a composer issue but when i try to install contao bootstrap bundle, i get an "Out of Memory error"
I'm using Contao 3.5.6 with composer 0.16 - hosted on a 1&1 shared server (maximum allowed memory for php : 81 MB)
Any idea ?