Excessive memory usage #8381
Comments
|
This bug report is missing a link to reproduction at phpstan.org/try. It will most likely be closed after manual review. |
|
Did you try using more memory: You should use Also, you could try running on only one folder ( |
|
@VincentLanglet, the weird issue is that it doesn't happen all the time. Now I ran with debug and the check passed. I can only see some peaks of consumed memory but overall it passed. Will run several times to catch the failure Details |
Because of |
|
Anyway, it doesn't matter because this runs in CI, on clean. So, there are no previously cached results |
|
there's also a known problem with huuuuge stub files. we triggered that with the phpstan-wordpress extension and a stub file auto-generated from wordpress docs. not sure though what the drupal extension exactly is doing in that regard |
|
So, I can confirm that it cannot be reproduced with |
|
Any idea how to debug without |
|
I guess you could try to divide and conquer the files beeing analyzed to narrow down where most memory is spent? |
|
another thing you could try: reduce usage of custom rules or on-top rule packages to see whether the problem lies in phpstan-src itself or in a extension |
|
I tried to run selectively only some directories. Unfortunately, the results are not consistent so I cannot pinpoint the code that creates the problem. What else? |
|
if it happens on a selective small set of files you could create a reproducing repo |
|
Well, as I said, I cannot narrow. I ran several tests that passed with some directories only to find that they start to fail. |
|
@claudiu-cristea Please use Markdown collapsible feature when adding long code samples. |
|
@javaDeveloperKid didn't know that feature exists. Fixed, thank you |
|
After tons of tests, I can confirm that only fails when running w/o |
|
I prepared PR that outputs how much memory was used in parallel mode. Once it gets merged, you can try it locally and then adapt number of CPUs (the less cores used, the less memory it consumes in parallel mode) to lower it under your 4G. |
|
I'm using: php ./vendor/bin/phpstan --version
PHPStan - PHP Static Analysis Tool 1.9.3with php -v
PHP 8.1.13 (cli) (built: Nov 26 2022 14:07:55) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.1.13, Copyright (c) Zend Technologies
with Zend OPcache v8.1.13, Copyright (c), by Zend TechnologiesAnd Stuck at this point about 10 minutes while RAM is begin drained:
Composer dependencies are: "require": {
"php": "^8.1",
"composer/composer": "^2.2",
"doctrine/dbal": "^3.0",
"laravel/framework": "^9.5",
"laravel/helpers": "^1.2",
"mateusjunges/laravel-kafka": "^1.8",
"predis/predis": "^1.1",
"sentry/sentry-laravel": "^3.0"
},
"require-dev": {
"friendsofphp/php-cs-fixer": "^3.9",
"laravel/pint": "^1.0",
"nunomaduro/collision": "^6.1",
"nunomaduro/larastan": "^2.0",
"nunomaduro/phpinsights": "dev-master",
"phpstan/phpstan": "^1.4"
},
"config": {
"optimize-autoloader": true,
"preferred-install": "dist",
"sort-packages": true,
"allow-plugins": {
"composer/package-versions-deprecated": true,
"dealerdirect/phpcodesniffer-composer-installer": true
}
},And includes:
- ./vendor/nunomaduro/larastan/extension.neon
parameters:
paths:
- app/
level: 5
ignoreErrors:
- '#Access to an undefined property App\\Services\\Mirakl\\Resource\\#'
- '#Access to an undefined property Illuminate\\Contracts\\Auth\\Authenticatable#'
- '#Access to an undefined property object::#'
- '#Access to an undefined property .*Abstract#'
- '#Access to an undefined property .*\\Model#'
- '#Access to undefined .*Abstract#'
- '#App\\Domains\\User\\Model\\User.* does not accept Illuminate\\Contracts\\Auth\\Authenticatable#'
- '#Call to an undefined .*Abstract#'
- '#expects App\\Domains\\Shared\\Model\\ModelAbstract\|null, Illuminate\\Contracts\\Auth\\Authenticatable\|null given#'
- '#of parent class Illuminate\\Database\\Eloquent\\Builder#'
- '#of parent class Illuminate\\Database\\Eloquent\\Relations#'
- '#Property App\\Domains\\.* does not accept Illuminate\\Database\\Eloquent#'
- '#returns .*Abstract.#'
- '#should return App\\Domains\\.*\\Model.* but returns Illuminate\\Database\\Eloquent\\Model#'
- '#\\Domains.*\\Model\\.*Illuminate\\Database\\Eloquent\\Model given#'
- '#Unsafe usage of new static#' |
|
@eusonlito Please open a new issue for your problem and recreate it in a small repository. Thanks. |
|
@ondrejmirtes ok, sorry :) I have found the class with the problem. I will try to reproduce in a clean repository. |
|
The memory usage will be greatly improved in PHPStan 2.0. Right now you can try it with bleedingEdge: https://phpstan.org/blog/phpstan-1-6-0-with-conditional-return-types#lower-memory-consumption I don't see anything actionable in this issue - if you have a specific code example, please open a new one. Thanks. |
|
Thanks @ondrejmirtes, I'm checking what is the problem inside a Laravel Model with a Trait. Removing the Trait the process can finish, with the trait, it stuck consuming all available memory. The app as it self is working without problem. |
|
@ondrejmirtes maybe the problem I've described in #8381 (comment)? The fact that, with debug, there's no memory overflow. There's a difference between memory consumption. Than makes debug not useful when trying to debug such cases |
|
@claudiu-cristea No, definitely not. With The problem @eusonlito isn't related to excessive memory consumption, but it's triggering a bug that makes PHPStan end up in an infinite recursion. |
|
@claudiu-cristea my problems are with and without |
This was referenced Dec 16, 2022
|
Sorry @ondrejmirtes but my two issues was auto-closed by bot :( I think that there are nothing bad with my issues... |
|
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug report
We're using PHPStan to check our code for https://git.fpfis.tech.ec.europa.eu/ec-europa/digit-joinup-reference. As it's a Drupal project we're also using
mglaman/phpstan-drupalWe run this command:But in our CI pipelines the process often breaks with...
...which indicates a memory issue, particularly excessive memory usage.
We don't have control of the pipeline, neither can we determine the container resources such as the memory. However, it looks like PHPStan needs a lot of memory to run.
Code snippet that reproduces the problem
N/A
Expected output
Is there a chance to improve/optimize the memory usage?
Did PHPStan help you today? Did it make you happy in any way?
It's a great tool.
The text was updated successfully, but these errors were encountered: