opened
zayders
username_0
My `composer.json`:

```json
{
    "name": "symfony/framework-standard-edition",
    "license": "MIT",
    "type": "project",
    "description": "The \"Symfony Standard Edition\" distribution",
    "autoload": {
        "psr-4": { "": "src/" },
        "classmap": [ "app/AppKernel.php", "app/AppCache.php" ]
    },
    "autoload-dev": {
        "psr-4": { "Tests\\": "tests/" }
    },
    "require": {
        "php": ">=5.5.12",
        "symfony/symfony": "3.4.*",
        "doctrine/orm": "^2.5",
        "doctrine/doctrine-bundle": "^1.6",
        "doctrine/doctrine-cache-bundle": "^1.2",
        "symfony/swiftmailer-bundle": "^2.3",
        "symfony/monolog-bundle": "^3.0",
        "symfony/polyfill-apcu": "^1.0",
        "sensio/distribution-bundle": "^5.0",
        "sensio/framework-extra-bundle": "^3.0.2",
        "incenteev/composer-parameter-handler": "^2.0",
        "twig/extensions": "~1.0",
        "doctrine/doctrine-fixtures-bundle": "~2.3",
        "symfony/assetic-bundle": "^2.7.1",
        "leafo/scssphp": "~0.6",
        "patchwork/jsqueeze": "~1.0",
        "coresphere/console-bundle": "dev-master",
        "friendsofsymfony/user-bundle": "dev-master",
        "egeloen/ckeditor-bundle": "^4.0",
        "jms/serializer": "^1.7",
        "vich/uploader-bundle": "^1.4",
        "liuggio/excelbundle": "^2.1",
        "spipu/html2pdf": "^5.0",
        "ob/highcharts-bundle": "^1.6",
        "ocramius/proxy-manager": "^1.0",
        "oneup/uploader-bundle": "^1.9"
    },
    "require-dev": {
        "sensio/generator-bundle": "^3.0",
        "symfony/phpunit-bridge": "^4.1"
    },
    "scripts": {
        "symfony-scripts": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
        ],
        "post-install-cmd": [
            "@symfony-scripts"
        ],
        "post-update-cmd": [
            "@symfony-scripts"
        ]
    },
    "config": {
        "platform": {
            "php": "5.5.12"
        }
    },
    "extra": {
        "symfony-app-dir": "app",
        "symfony-bin-dir": "bin",
        "symfony-var-dir": "var",
        "symfony-web-dir": "web",
        "symfony-tests-dir": "tests",
        "symfony-assets-install": "relative",
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        },
        "branch-alias": {
            "dev-master": "3.2-dev"
        }
    }
}

```

Output of `composer diagnose`:

```
Checking composer.json: WARNING
Defining autoload.psr-4 with an empty namespace prefix is a bad idea for performance
require.coresphere/console-bundle : unbound version constraints (dev-master) should be avoided
require.friendsofsymfony/user-bundle : unbound version constraints (dev-master) should be avoided
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys: 
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.7.3
PHP version: 5.5.12 - Package overridden via config.platform (same as actual)
PHP binary path: D:\wamp\bin\php\php5.5.12\php.exe

```

When I run this command:

```
php ..composer.phar update
```

I get the following output:

```
Fatal error: Out of memory (allocated 1520435200) (tried to allocate 268435456 b
ytes) in phar://D:/wamp/www/composer.phar/src/Composer/DependencyResolver/Solver
.php on line 220
```

And I expected this to happen:

Update all dependencies

I try several solution but nothing is working :

- My php.ini is already modify with memory_limit = -1

- the command php -d memory_limit=-1 ../composer.phar update

- The command php ../composer.phar install (work fine but after i have the same error when i run composer update)

- Try composer self-update to get last version

- Try to edit composer.bat to up the memory

- I'm on php 5.5.12, i can't upgrade to php 7.X due to my restrictions. And i tried to upgrade to php 5.6 and it not solve the problem, always this error : "Out of memory"

My computer has 4Gb RAM and about 2,4 available when i want to execute the command
Fatal Error : out of memory with Composer Update
issue
created
alcohol
username_1
Your error indicates it is not hitting the imposed limit, but rather a physical limit. You are literally out of memory. There is not much we can do from our end about this. I would suggest you try to narrow your constraints as much as possible.
comment
created
myspulin
username_2
Hi Guys, I have spent couple hours to solve memory issue during composer upate on my projects. I have the latest version of composer 1.7.3, run PHP 7.2, OS win7 x64, RAM 16GB and have no luck at all. On overy project it gives me out of memory. I have changed memory limit to unlimited, no luck, which is strange. I have checked the code inside composer.phar and find out this code:

// Increase memory_limit if it is lower than 1.5GB
    if ($memoryLimit != -1 && $memoryInBytes($memoryLimit) < 1024 * 1024 * 1536) {
        @ini_set('memory_limit', '1536M');
    }

So the memory limit is set to 1.5GB minimum, which is not enough in my case. 

The solution on my installation was to switch from 32bit to 64bit version of PHP. Reason is simple, to get more than 2GB memory available. When I run composer with command:

php -d memory_limit=-1 composer.phar update --profile -vvv

It gives me at the end of success run this result: Memory usage: 322.37MB (peak: 1804.41MB), time: 178.78s

So memory usage is really high and maybe is time to talk about necessity to use composer with PHP 64bit as 32bit has 2GB memory limitation. I went through so many discussion about this issue but mostly there is no solution. As this issue is here so long time and obviously I am not alone should be nice to update official documentation to mention this option.

Thank you, love composer so much!

Best regards, Lukas
comment
created
zayders
username_0
Hi @username_1  @username_2 , thanks for your reply, due to restriction of my IT department, i'm on Windows 7 32 bit, is there any problem to install php 64 bit on OS 32 bit ? I think it's not the better thing to do but i don't really know. If it's a problem, maybe i could ask them to pass on OS 64 bit. I have a lot of restriction, it's complicated.
comment
created
myspulin
username_2
Hi @username_1 , you can't run 64bit PHP on 32bit OS, but regarding your restriction, there is a way to use some kind of virtualization. For example VirtualBox supports 64-bit guest operating systems, even on 32-bit host operating systems. So I beleave this should be your first option. Le tme know.
comment
created
YetiCGN
username_3
I already switched to 64-bit PHP executable and now Composer is telling me that at 3.174 gibibytes it still needs an additional 512 MiB. The German error message says that my page file is too small to continue. Why would Composer need so much memory? My `require` section isn't that huge:

    "require": {
        "php": "^7.0",
        "sulu/sulu": "^1.6.3",
        "twig/extensions": "^1.0",
        "symfony/monolog-bundle": "^2.4",
        "sensio/distribution-bundle": "^5.0",
        "sensio/framework-extra-bundle": "^3.0.2",
        "incenteev/composer-parameter-handler": "^2.0",
        "dantleech/phpcr-migrations-bundle": "0.1.*",
        "zendframework/zend-stdlib": "^2.3",
        "zendframework/zendsearch": "@dev",
        "massive/build-bundle": "^0.3",
        "jackalope/jackalope-doctrine-dbal": "^1.2.5",
        "jackalope/jackalope-jackrabbit": "^1.2.0",
        "doctrine/doctrine-fixtures-bundle": "2.2.*",
        "doctrine/doctrine-bundle": "^1.0",
        "doctrine/doctrine-cache-bundle": "^1.0",
        "oro/doctrine-extensions": "^1.0",
        "sensio/generator-bundle": "^3.0",

        "sulu/theme-bundle": "^1.2",
        "symfony/assetic-bundle": "^2.0",
        "matthiasmullie/minify": "^1.3"
    },

@username_1 You recommend "I would suggest you try to narrow your constraints as much as possible." 
Doesn't that defeat the point of Composer and its SAT solver if I have to specify exact versions and keep track of updates manually? Or how could the above composer file be improved for this?
comment
created
curry684
username_4
Of course that defeats the purpose, but it's also exactly inherent of SAT solving that it tries to find an optimal solution for the presented constraints, and their constraints, and their constraints. You should keep in mind that if you specify a Semver constraint on a package allowing 10 possible versions, that *each of those 10 may have different dependencies and constraints themselves*. So a solution may, even with very small require lists, require millions of solutions to be evaluated before an acceptable one is found.

So yes, it defeats the purpose of SAT to artificially limit the number of possible solutions by narrowing down constraints. The alternative is to keep adding RAM until all possible solutions fit. You can't have both.

In your specific case - Doctrine Bundle is at 1.10, specifying `^1.10` would eliminate about 20 candidates. Doctrine Cache Bundle is at 1.3.5, specifying `^1.3.5` would eliminate about 25 candidates. By specifying `^1.0` for both you are forcing Composer to evaluate 20*25 = about 500 (!) times as many root package permutations, and all their own recursive dependencies, than strictly necessary. So yes, by applying similar logic to all your includes you can likely make it work with less than 2GB again, and resolve a solution 10+ times faster as well. On a require list that's obviously an application and not a library, and as such has no need whatsoever to maintain support for all those bundle versions.

As a practical developer I'd go with the advice to make it a lot faster and use a lot less memory despite the theoretically entirely correct statement that SAT should resolve the exact same solution.
comment
created
curry684
username_4
There may actually be a use case I think to have a `composer optimize` command, which takes root constraints like this and makes them a ton more efficient by rewriting them from the lock file. So if, in this specific case, `doctrine/doctrine-cache-bundle` was resolved to 1.3.5 in a successful solution, we could replace the constraint safely with `^1.3.5` and it would by definition produce the same solution.

Potential risk would be people running it on libraries as well which could be dangerous, but we could print some nasty warnings if `composer.json` type is not `project`.

@username_7 whatcha think of this?
comment
created
YetiCGN
username_3
Now that's a great idea. I've done so here and there, updating constraints to newer versions but not excessively. This is a rather long-running project which saw it's first incarnation in April 2017. Some dependencies haven't been updated since in the `composer.json`.

But I can totally live with that recommendation, often update your constraints to exclude older versions that are irrelevant. If Composer would ship a command to do that on `"type": "project"` like you sketched out, that would be wonderful!

By the way, I was able to successfully update now after closing everything else down. Composer peaked at 5,780 MiB RAM usage for quite a few minutes but it worked.
comment
created
curry684
username_4
Just did a practical test on a huge Symfony application I'm working on, running `composer update --profile` with 65 root dependencies including dev:
```
[383.7MB/105.42s] Memory usage: 383.74MB (peak: 771.84MB), time: 105.42s
```
Not even 800MB of peak memory usage, less than 2 minutes. Just by occasionally narrowing down constraints when upgrading.

(disclaimer: 65 dependencies including 25-something Symfony 4.x components managed by Symfony Flex which has its own optimizations).
comment
created
xabbuh
username_5
@username_4 Your suggestion reminds me of #7273.
comment
created
iltar
username_6
Recently I ran into this issue again, turns out the fix was indeed to narrow down the possible constraints again.
comment
created
curry684
username_4
It would likely make the process more than 10 times faster with 10% of the RAM. Feel free to issue a PR   😉
comment
created
curry684
username_4
@username_3 did you update your Composer version recently? I just tried `composer update --profile` on the unoptimized `composer.json` you provided above in a VM without any caches so it had to download everything, and got this:
```
[374.5MB/379.78s] Memory usage: 374.55MB (peak: 1841.85MB), time: 379.78s
```
That's less than a third of what you claim your optimized version is using. Could it be that your `composer.phar` is as old as the project?   😉
comment
created
curry684
username_4
I decided to continue the test. After the above solution, I checked which versions of root packages were resolved:
```
dantleech/phpcr-migrations-bundle    0.1                PHPCR migrations bundle
doctrine/doctrine-bundle             1.10.0             Symfony DoctrineBundle
doctrine/doctrine-cache-bundle       1.3.5              Symfony Bundle for Doctrine Cache
doctrine/doctrine-fixtures-bundle    v2.2.1             Symfony DoctrineFixturesBundle
incenteev/composer-parameter-handler v2.1.3             Composer script handling your ignored parameter file
jackalope/jackalope-doctrine-dbal    1.3.2              Jackalope Transport library for Doctrine DBAL
jackalope/jackalope-jackrabbit       1.3.2              Jackalope Transport library for Jackrabbit
massive/build-bundle                 0.3.1              Massive Art Build Bundle
matthiasmullie/minify                1.3.61             CSS & JavaScript minifier, in PHP. Removes whitespace, strips comments, combines files (incl. @import statements and small assets in CSS files), and optimizes/shortens a few commo...
oro/doctrine-extensions              1.2.2              Doctrine Extensions for MySQL and PostgreSQL.
sensio/distribution-bundle           v5.0.24            Base bundle for Symfony Distributions
sensio/framework-extra-bundle        v3.0.12            This bundle provides a way to configure your controllers with annotations
sensio/generator-bundle              v3.1.7             This bundle generates code for you
sulu/sulu                            1.6.23             Sulu core distribution
sulu/theme-bundle                    1.3.2              The Sulu Bundle which provides themes
symfony/assetic-bundle               v2.8.2             Integrates Assetic into Symfony2
symfony/monolog-bundle               v2.12.1            Symfony MonologBundle
twig/extensions                      v1.5.4             Common additional features for Twig that do not directly belong in core
zendframework/zend-stdlib            2.7.7             
zendframework/zendsearch             dev-master c8de250 a general purpose text search engine written entirely in PHP 5
```
And adapted my `composer.json` accordingly, ,following the "rules" I outlined above only replacing pure caret constraints with the resolved version:
```json
"require": {
    "php": "^7.0",
    "sulu/sulu": "^1.6.23",
    "twig/extensions": "^1.5.4",
    "symfony/monolog-bundle": "^2.12.1",
    "sensio/distribution-bundle": "^5.0.24",
    "sensio/framework-extra-bundle": "^3.0.12",
    "incenteev/composer-parameter-handler": "^2.1.3",
    "dantleech/phpcr-migrations-bundle": "0.1.*",
    "zendframework/zend-stdlib": "^2.7.7",
    "zendframework/zendsearch": "@dev",
    "massive/build-bundle": "^0.3.1",
    "jackalope/jackalope-doctrine-dbal": "^1.3.2",
    "jackalope/jackalope-jackrabbit": "^1.3.2",
    "doctrine/doctrine-fixtures-bundle": "2.2.*",
    "doctrine/doctrine-bundle": "^1.10.0",
    "doctrine/doctrine-cache-bundle": "^1.3.5",
    "oro/doctrine-extensions": "^1.2.2",
    "sensio/generator-bundle": "^3.1.7",

    "sulu/theme-bundle": "^1.3.2",
    "symfony/assetic-bundle": "^2.8.2",
    "matthiasmullie/minify": "^1.3.61"
}
```
It got a lot faster, but indeed not much less RAM:
```
[374.6MB/113.96s] Memory usage: 374.59MB (peak: 1741.24MB), time: 113.96s
```
At which point I realized something that was bugging me before about the `composer.json` you provided - there was no explicit mention of Symfony anywhere, you're depending on a full stack Symfony version being decided on recursively, which eventually leads to `symfony/symfony:2.8.49` being installed. This is highly dangerous, as many of those libraries are compatible with a lot of Symfony versions (ie. `^2.8 || ^3.2 || ^4.0`, or `>2.8` or similar incredibly wide constraints, given the amount of releases Symfony has. This is more or less the exact reason Symfony Flex was developed, to battle the sheer amount of Symfony packages Composer has to consider that are compatible with hundreds of other packages.

So I added a single line to your require list:
```
    "symfony/symfony": "^2.8.49"
```
And ran `composer update --profile` again:
```
[341.0MB/12.23s] Memory usage: 340.96MB (peak: 1172.99MB), time: 12.23s
```
Achievement unlocked - from 380 seconds down to 12 with 2 simple optimizations aimed at making Composer's life easier   😉 

This leaves the question why in 12 seconds it's still using 1.2GB of RAM. The answer to that is also simple actually - Composer is optimized towards up to date development. It downloads and processes package info for the last 3 months first, and starts to load older data incrementally as it turns out to be needed by the solver. This way in the case of Symfony for example it can skip years of outdated versions if you're just working with the current 4.2 release. In your case you *are* using 3 year old dependencies, giving it little other choice than to "waste" over a GB of RAM on more or less the past 5 years of Packagist releases. Hence why my much bigger project only used 778MB of RAM - it's on Symfony 4.2 with cutting edge dependencies.

Hope this all explains a lot, and happy coding now your `composer update` only takes 10~12 seconds   😆
comment
created
zayders
username_0
Hi everyone ! I had possibility to have a new OS version : x64 and to upgrade my php to 7.2 in x64. It solve my problem, i can run any command with composer. My computer is still the same, 4Go RAM but with OS and PHP x64 (7.2).
So it works perfectly with `php -d memory_limit=-1 ../composer.phar update`

Thanks for your help !
comment
created
YetiCGN
username_3
No, it's 1.8.0 😄 I update Composer regularly.

I did, however, do some research as well. Since I wanted to know where the Symfony dependency comes from, but for a totally different reason: I was wondering why it was still at 2.8 when my other Sulu projects are at 3.4 already. It turns out, in this project we used `sulu/sulu` but since have started our newer projects with `sulu/sulu-minimal` (as recommended by [the Sulu documentation](http://docs.sulu.io/en/latest/book/getting-started.html)). I think this might be a lead I will try to explore next, drop the full CMF framework dependency and only require `sulu-minimal` and what I really need.
comment
created
YetiCGN
username_3
Sulu does however have a lot of dev dependencies for the full package: https://packagist.org/packages/sulu/sulu

I didn't think about dev dependencies, because the only one in my project is:

    "require-dev": {
        "phpcr/phpcr-shell": "^1.1.1"
    },

But just now I took another good look at what `sulu/sulu` requires for dev. Running `composer update --no-dev --profile` yields similar values, though.
comment
created
Seldaek
username_7
Gonna close this because we have https://github.com/composer/composer/issues/7273 open and also because Composer 2.0 will behave quite differently there so I think let's give it some time and see what comes of that effort. In the meantime yes please restrict your constraints manually as much as possible, that'll help.
comment
closed
Seldaek
username_7
issue
created
YetiCGN
username_3
Requiring Symfony explicitly indeed reduced the runtime a lot (half of that time is spent in the post-update-scripts) and memory usage by 37%:

    [511.1MB/201.09s] Memory usage: 511.13MB (peak: 3774.46MB), time: 201.09s

Thanks for your analysis!
comment
created
curry684
username_4
`composer why symfony/symfony`   😉
comment
created
YetiCGN
username_3
No, I used `composer why-not symfony/symfony:3.4` 😛
comment
created
curry684
username_4
Both would show the problem, as the first one will list all recursive requirements causing the package to be selected, with their respective constraints.
comment
created
YetiCGN
username_3
Funny. This week I pegged the Symfony version to "3.4.20" as a quick fix because 3.4.21 broke another dependency. This resulted in a much lower memory usage of 2,071 MB peak RAM usage instead of the 3.7 or 4+ GB I was seeing before. Today I set it back to "^3.4.21" because the bug was fixed and now `composer update` is memory heavy again. If there is only one version that applies to the range "^3.4.21", why is there a difference between setting the exact version and using the ^ operator?
Could this be optimized to the point where there is a check if the range with regards to the chosen stability setting resolves to exactly one version and then use this version as if it were set without a range?
comment
created
curry684
username_4
The behavior you describe surprises me, I have no clue why it would work like this. Makes me curious to see whether it's reproducable with for example `^3.4.18` and `3.4.18` right now (following your theory it would be 4 times more inefficient).
comment
created
YetiCGN
username_3
Dang, sorry. I can't reproduce this now. I guess the additional memory usage came from Composer having to really update Symfony to 3.4.21. If I run the `composer.json` with profiling and debugging enabled, the memory usage and runtime is almost equal between "3.4.21" and "^3.4.21":

```
[343.8MB/13.51s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
[1459.2MB/48.02s] After getRulesFor
[1459.3MB/48.03s] After checkForRootRequireProblems
[1459.3MB/48.03s] After new Decisions
[2065.5MB/54.18s] Resolving dependencies through SAT
[2070.7MB/54.29s] Looking at all rules.
[2071.1MB/56.52s] [2071.4MB/58.71s] Something's changed, looking at all rules again (pass #2)[2071.4MB/58.71s]          [2071.4MB/60.88s] Something's changed, looking at all rules again (pass #3)[2071.4MB/62.10s]
[2071.4MB/62.10s] Dependency resolution completed in 7.921 seconds
[2071.4MB/62.16s] Analyzed 20792 packages to resolve dependencies
[2071.4MB/62.16s] Analyzed 3401876 rules to resolve dependencies
[2071.4MB/62.16s] Nothing to install or update
```

But by digging into the code, I gained a valuable insight: The SAT solver itself isn't the memory hog, it's `RuleSetGenerator->getRulesFor`.
comment
created
curry684
username_4
That generates the rules for SAT to solve to use so technically it's the same  😉
comment
created
YetiCGN
username_3
Semantics. 😛 

I think I was chasing gremlins, I tried your suggestion with ^3.4.18 and then with 3.4.18 and it had about the same footprint, even though there was a downgrade on the latter `update`. Even though there were 34,689 more rules to resolve, this 1% increase was hardly noticable.

^3.4.18:
```
[343.7MB/9.56s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
[1464.7MB/41.68s] After getRulesFor
[1464.7MB/41.68s] After checkForRootRequireProblems
[1464.7MB/41.69s] Before building watch graph
[2076.8MB/47.27s] After building watch graph
[2076.8MB/47.86s] Resolving dependencies through SAT
[2082.0MB/47.96s] Looking at all rules.
[2082.4MB/50.40s] [2082.6MB/52.66s] Something's changed, looking at all rules again (pass #2)[2082.6MB/52.66s]          [2082.6MB/54.90s] Something's changed, looking at all rules again (pass #3)[2082.6MB/56.55s]
[2082.6MB/56.55s] Dependency resolution completed in 8.688 seconds
[2082.7MB/56.62s] Analyzed 20792 packages to resolve dependencies
[2082.7MB/56.62s] Analyzed 3436565 rules to resolve dependencies
[2082.7MB/56.62s] Nothing to install or update
```
3.4.18:
```
[343.7MB/9.58s] Reading C:/Users/jwagner.AD/AppData/Local/Composer/repo/https---repo.packagist.org/provider-zendframework$zendsearch.json from cache
[1459.0MB/46.31s] After getRulesFor
[1459.1MB/46.31s] After checkForRootRequireProblems
[1459.1MB/46.31s] Before building watch graph
[2065.3MB/52.27s] After building watch graph
[2065.3MB/52.80s] Resolving dependencies through SAT
[2070.5MB/53.08s] Looking at all rules.
[2070.9MB/55.23s] [2071.2MB/57.44s] Something's changed, looking at all rules again (pass #2)[2071.2MB/57.44s]          [2071.2MB/59.58s] Something's changed, looking at all rules again (pass #3)[2071.2MB/60.88s]
[2071.2MB/60.88s] Dependency resolution completed in 8.076 seconds
[2071.2MB/61.05s] Analyzed 20792 packages to resolve dependencies
[2071.2MB/61.05s] Analyzed 3401876 rules to resolve dependencies
[2072.0MB/61.06s] After setupInstalledMap
[2072.6MB/61.08s] After getRulesFor
[2072.6MB/61.08s] After checkForRootRequireProblems
[2072.6MB/61.08s] Before building watch graph
[2072.8MB/61.08s] After building watch graph
[2072.8MB/61.08s] Resolving dependencies through SAT
[2072.9MB/61.09s] Looking at all rules.
[2072.9MB/61.09s]
[2072.9MB/61.09s] Dependency resolution completed in 0.002 seconds
[2071.8MB/61.09s] Package operations: 0 installs, 1 update, 0 removals
[2071.8MB/61.09s] Updates: symfony/symfony:v3.4.18
[2071.8MB/61.10s]   - Downgrading symfony/symfony (v3.4.21 => v3.4.18)
[...]
[399.9MB/212.23s] Memory usage: 399.89MB (peak: 2081.94MB), time: 212.23s
```
comment
created
curry684
username_4
Yep, that's what I would expect to see, as the constraint covers 3 more versions it causes a few more rules to be generated, but as all 4 have the same dependencies themselves it shouldn't really impact the whole process a lot.l
comment
created
shadman
username_8
You may also get resolved by just removing vendor directory and re-execute composer install command.
comment
created
vinika02
username_9
Hi, this solution will fix your problem.

Update your php.ini file then restart Apache or your server

It's work on me.
comment
created
vinika02
username_9
Hi, this solution will fix your problem.

Update your php.ini file then restart Apache or your server
example:
memory_limit=128M
to 
memory_limit=1128M


It's work on me.
comment
created
YetiCGN
username_3
Wouldn't work for me, as you see above, because Composer needs over 6 GB of RAM. You can set it to unlimited with `-1` as well. Still you might hit a hardware memory limit.
comment