-
Notifications
You must be signed in to change notification settings - Fork 221
Memory issue in v0.13 #721
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi,
|
While updating from 0.11.11 to 0.13.3, the following dependencies has been updated:
Then I downgraded to overblog/graphql-bundle from 0.13.3 to 0.12.8 but no other dependencies has been downgraded... So it means that the issue comes from the bundle 😕 |
I've done some tests today, and this is what I found. The memory leak also happens when running Behat tests not on the GraphQL API. For example some classical tests on our controllers (
I can confirm the issue is also present in 0.13.0, so something wrong should have happens in v0.12.8...v0.13.0 |
Hi @Kocal Did the php version remain the same? |
Hi @akomm, Oh my bad, I didn't say what version of PHP I'm using. |
If neither your tests change, nor A small chance also that some memory leak bug in the php version that was not triggered before is triggered after the changes, so if you swap the php version you might quickly exclude this case. Provided your dependencies allow for an increase to let's say 7.4 ... |
I did some blackfire traces:
I really don't know what can happens, but I guess we will have to update PHP from 7.3 to 7.4... 😬 ping @tristanbes / @RomulusED69 |
@Kocal there are some reports in internet about memory leak in PHP 7.3 |
@murtukov yes, I have checked for this, but found only some in 7.3.2m which supposedly were fixed. However, I agree, as I also said myself, there might still be some I/you missed or some, which nobody found yet ;) |
Actually, when I check the logs, there are dozens of memory leaks closed after 7.3.2: https://www.php.net/ChangeLog-7.php , including 7.4.0+ |
The diff php 7.3 is rather interesting. If you analyze / sort by memory usage, you find the main troublemaker is This increase everywhere, rather than at the top of the (filtered) stack is a sign of there being a memory leak that affects everything. But A last note on this: leak for me is not only bug, but might also be accidentally caused by code or having some profiling enabled (symfony, debugger, etc.). PHP7.4 might just circumvent it with the new memory optimizations they have added. I also recall there was a feature adding some profiling for graphql in recent updates, just to name an example. Not sure though which version it was. |
Little update: we're migrating a project step by step and we hit a wall with 0.13. The test suite no longer runs due to huge memory leaks. A standard test can see deviations as high as +280% of memory usages. It's a bit late so I'm gonna stop here but from what I could collect, the issue is not so much of a higher memory consumption, but rather a leakage, and I can trace source of the problem here. If I replace the content with: public function __construct($name, callable $compiler, ?callable $evaluator = null)
{
if (null === $evaluator) {
$evaluator = static function () {};
}
parent::__construct($name, $compiler, $evaluator);
} Then the memory leak issue is gone. My suspicion is that you're allocating an exception which can never be garbage collected resulting in the leak. |
@theofidry is this the file you are talking about ? I think we can replace this exception by a warning. Maybe you have a better solution ? |
@mcg-web indeed; I just vendor hotfixed it to the old code (a static function throwing an exception) and it worked just fine. There is still a significant memory increase but not as much leak (which was a problem since quickly resulting in a bailout when running the test suite). I am not exactly sure why, I assume because you made it an actual exception it probably captures the stack trace & everything. So maybe it's not much that the evaluator is not release (it's probably not release in any case), but more that the memory footprint is much bigger. |
Closes overblog#721. Follow up of [my comment](overblog#721 (comment)). I cannot investigate further, but my guess is that exceptions are not cheap objects. When creating an exception you also capture the context and stack trace which means that even if the extension is unsued: - it slows down the program because instantiating it is not cheap - may prevent some objects to be garbage collected because referenced in the exception
Hi,
I'm still working on GraphQLBundle update from 0.11 to 0.13 on our big app at work, but I detected a memory issue while running our Behat suite tests.
It does not affect 0.11 and 0.12.
I've recorded
htop
output while running behat:Do you have an idea of what can happens?
Thanks!
The text was updated successfully, but these errors were encountered: