Sentry-php: Dependency keeps hitting memory limits

[Christophvh]

Hi,

Recently all my projects using sentry hit memory issues when trying a 'composer update'. The only solution is to remove the sentry-dependency and after that composer update works fine. The issue seems with this dependency: "jean85/pretty-package-versions": "^1.2",

Is this necessary? Also why use a wrapper instead of the main package? https://github.com/Ocramius/PackageVersions

I'm using the sentry-laravel package but it seems the problem is not related to that.

[Jean85]

Why do you think that specific package is the culprit? The Sentry package has more than a few deps, and a small package like that one can't be the only cause.

Which version of PHP and Composer are you using? Have you tried reducing/bumping all your other constraints to reduce the amount of memory used by Composer's SAT?

[stayallive]

Copied my comment from getsentry/sentry-laravel#343 for reference.

There can be many reasons why this is happening but I cannot imagine Sentry causes this (I've never encountered this yet), it might be Sentry with some other dependencies in your project where composer need to do some advanced conflict resolution to figure out what versions to install for certain packages.

But on first glance this seems more like a composer issue than Sentry.

Are you able to share your composer.json to see if I can reproduce it on my end and see if I can track down the error?

[Christophvh]

Why do you think that specific package is the culprit? The Sentry package has more than a few deps, and a small package like that one can't be the only cause.

Which version of PHP and Composer are you using? Have you tried reducing/bumping all your other constraints to reduce the amount of memory used by Composer's SAT?

You are correct I can't be sure that that dependency is the culprit. I assumed so because before all the spam from this package in my console I didn't have that issue. Using composer 1.10.5 but have had issues with 1.9.5 and up. I have this problem in multiple projects, ranging from PHP version 7.2 - 7.4

I also want to add that I updated all my dependencies without problem. Afterwards i ran composer require sentry/sentry-laraveland instantly hit the memory limit. That really doesn't seem to be related to bumping my version numbers.

My colleague also faces this issue, so it doesn't seem related to my computer. I have tested it both on my Mac and inside a vagrant machine. We use Homestead vagrant boxes for most of our projects. I have increased memory on the vagrant boxes to 4GB with 3cpu-cores. I also tried to up the PHP limit and the only value that works is -1

@stayallive
Example of a failing project:

    "require": {
        "php": "^7.2",
        "ebess/advanced-nova-media-library": "^2.9",
        "eminiarts/nova-tabs": "^1.2",
        "fideloper/proxy": "^4.0",
        "guzzlehttp/guzzle": "^6.5",
        "laravel/framework": "^6.0",
        "laravel/horizon": "^3.7",
        "laravel/nova": "^2.9",
        "laravel/socialite": "^4.3",
        "laravel/tinker": "^1.0",
        "league/flysystem-aws-s3-v3": "^1.0",
        "league/flysystem-cached-adapter": "^1.0",
        "maatwebsite/laravel-nova-excel": "^1.1",
        "mll-lab/graphql-php-scalars": "^3.0",
        "mll-lab/laravel-graphql-playground": "^2.0",
        "nuwave/lighthouse": "^4.9",
        "sentry/sentry-laravel": "^1.7",
        "spatie/laravel-cors": "^1.6",
        "spatie/laravel-medialibrary": "^7.0.0",
        "spatie/laravel-permission": "^3.0",
        "spatie/laravel-tags": "^2.5",
        "spatie/nova-tags-field": "^2.3",
        "tymon/jwt-auth": "^1.0.0",
        "wappla/innovatieatelier": "*",
        "wildbit/swiftmailer-postmark": "^3.1"
    }

[Jean85]

Afterwards i ran composer require sentry/sentry-laravel and instantly hit the memory limit.

Requiring a new package is surely more memory-intensive than a simpler composer update.

That really doesn't seem to be related to bumping my version numbers.

Composer instantiate an object for each tag of each package (direct dependency and undirect too) that it has to consider. So, if you're using a package with constraint ^1.0 but you're already using 1.4.4, increasing the constraint to at least ^1.4 in your composer.json will help a lot with memory consumption.

I have increased memory on the vagrant boxes to 4GB with 3cpu-cores. I also tried to up the PHP limit and the only value that works is -1

You can increase the limit for Composer only with the env variable COMPOSER_MEMORY_LIMIT.

[Christophvh]

Not trying to be disrespectful but you're missing the point in almost all my answers. Yes, composer require is more intensive than composer update. But I'm comparing 1 single composer require. 0 problems with composer require if I don't have sentry installed. When I have sentry installed every single composer require hits memory limits. Yes version numbers count, but I just said that all my packages are 100% the latest version and the only thing I do is require sentry and it instantly hits memory issues. I spend 4 hours yesterday debugging this problem and the only thing that helps is setting the memory limit to unlimited or removing sentry.

If you think it's normal that on a 4GB machine with 3 cores that It can't handle to install sentry then you can close this issue because this conversation is pointless.

I also hit the below issue:
Maybe this is related: https://github.com/Ocramius/PackageVersions/issues/105

We are using 7.4 on this particular project, but the constraint in composer is 7.2 and up, which is the current Laravel default.

We pay for sentry, so should I make a separate support issue? Because it affects all our projects at work so it costs us money.

[stayallive]

@Christophvh I am trying to install your composer.json example, however I had to remove wappla/innovatieatelier:* since that package is not on packagist. I have added the Nova repository too since most packages require Nova.

I removed getsentry/sentry-laravel from composer.json and running composer install consumes 1.2GB of memory on my PHP 7.4.3 and composer 1.9.3.

Running composer require sentry/sentry-laravel afterwards required 1.4GB of memory. After removing the vendor file and composer.lock but leaving getsentry/sentry-laravel in the composer.json running composer install went back to using 1.2GB of memory (so with Sentry in the require section).

So this means that the require command did change the memory usage a bit (~200-300MB) but the composer install (without .lock file) did not impact the memory usage.

So running the following should work (assuming OS X):

php -d memory_limit=2048M `which composer` install
# or
php -d memory_limit=2048M `which composer` require getsentry/sentry-laravel

I have tested this with the following composer.json:

{
    "name": "memtest",
    "require": {
        "php": "^7.2",
        "ebess/advanced-nova-media-library": "^2.9",
        "eminiarts/nova-tabs": "^1.2",
        "fideloper/proxy": "^4.0",
        "guzzlehttp/guzzle": "^6.5",
        "laravel/framework": "^6.0",
        "laravel/horizon": "^3.7",
        "laravel/nova": "^2.9",
        "laravel/socialite": "^4.3",
        "laravel/tinker": "^1.0",
        "league/flysystem-aws-s3-v3": "^1.0",
        "league/flysystem-cached-adapter": "^1.0",
        "maatwebsite/laravel-nova-excel": "^1.1",
        "mll-lab/graphql-php-scalars": "^3.0",
        "mll-lab/laravel-graphql-playground": "^2.0",
        "nuwave/lighthouse": "^4.9",
        "spatie/laravel-cors": "^1.6",
        "spatie/laravel-medialibrary": "^7.0.0",
        "spatie/laravel-permission": "^3.0",
        "spatie/laravel-tags": "^2.5",
        "spatie/nova-tags-field": "^2.3",
        "tymon/jwt-auth": "^1.0.0",
        "wildbit/swiftmailer-postmark": "^3.1",
        "sentry/sentry-laravel": "^1.7"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://nova.laravel.com"
        }
    ]
}

The problem is that this requires a Nova license to be run so this complicates our debugging, and there is the missing wappla/innovatieatelier:* package which could have an impact.

So from my testing the impact is little and composer requiring 1GB-2GB of memory to run update or require is very normal as far as I know.

Running composer install with a existing .lock file required only 26MB so this high memory usage is only needed when updating or requiring new packages not by running composer install.

---

I tested the memory usage on OS X by running:

/usr/bin/time -l composer install

And looking for maximum resident set size, that number is in bytes.

[Christophvh]

Thanks for the tests.
wappla/innovatieatelier:* is not relevant since it is a 'theme' for nova. Composer clearly has some things to work on because 1-2GB to get some files from the internet and check some constraints is absolutely insane, but that is another issue.

Maybe 1 thing that might be different is that we use Laravel Homestead which is a Vagrant box. And we run composer update inside that vagrant box. But if that causes the issue, the issue is indeed related to homestead. The strange thing is that I tested it outside vagrant and inside, and both trigger memory issues. Also removing sentry instantly solves it. That part still confuses me.

1 gotcha that is a little strange. Sometimes remove the vendor folder + .lock fill will also solve the problem. composer install then sometimes just works, while update or 1 require will hit memory issues. Got it from this comment: https://stackoverflow.com/a/33342224/3493752

200-300MB for 1 package is still very high, but that seems an issue with composer and not with sentry. I just switched to a newer project and also hit the same problems. Different packages, same issue. This is very hard for you guys to debug and for me to give more info on, but it seems abnormal, we will just all switch to infinite memory here at work. Maybe some people will also hit this in the feature since my colleagues have the same issue.

[stayallive]

Every package is relevant, because it has it's own dependencies and that adds to the memory usage (also missing all require-dev packages too from your example, they also contribute...).

I know this seems insane, but it is a really complex problem composer is trying to solve. The more advanced projects and it's requirements get the more memory composer needs to try and figure out what it needs adding another package might not have tipped it over the balance until now, I can't speculate without knowing your environment.

That is why the composer.lock file is there to prevent needing this amount of memory on (for example) production servers or in CI and only need it locally to install or update packages.

Removing the vendor and lock file allows composer to start from a clean slate and does not have to take into account all installed packages which makes it a little easier as far as I understand how composer work.

For "fun" I also tried to composer require laravel/sanctum and it resulted in the same memory bump as for composer require getsentry/sentry-laravel so I don't understand how we contribute to this mess more than others in your environment, interesting to see if you have the same issues with composer require laravel/sanctum (or any other package) instead of composer require getsentry/sentry-laravel.

However seeing getsentry/sentry-laravel is installed quite a bit I don't think there is much we do wrong and/or can do to help you unfortunately 😢

[Christophvh]

Thanks for the effort. Not sure what to tell you, sanctum seems to have worked, but that is probably smaller. But yeah you can close it if you guys want, maybe some more people will stumble on it.

[stayallive]

I'm not sure what to tell you either, really sorry you seem to have this issue with Sentry specifically. You are the first to point this out to us and we are unable to reproduce any error or have a clue what we can do to improve.

If in the future you find something pointing to us causing this we would be more than happy to investigate again 👍

[darylteo]

Not to reopen but the memory limit seems to have been hit by flysystem-cached-adapter, and the following statement needs to be run

COMPOSER_MEMORY_LIMIT=-1 composer require league/flysystem-cached-adapter ~1.0

In case anyone else comes searching on the internet.