[Cache] fix memory leak when using PhpArrayAdapter #34839
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nicolas-grekas
force-pushed
the
cache-memleak
branch
2 times, most recently
from
6c43f6a
to
326a513
Compare
nicolas-grekas
force-pushed
the
cache-memleak
branch
from
326a513
to
4194c4c
Compare
fabpot
approved these changes
Dec 7, 2019
|
Thank you @nicolas-grekas. |
fabpot
added a commit
that referenced
this pull request
Dec 7, 2019
…s-grekas) This PR was merged into the 3.4 branch. Discussion ---------- [Cache] fix memory leak when using PhpArrayAdapter | Q | A | ------------- | --- | Branch? | 3.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #34687 | License | MIT | Doc PR | - Thanks to @adrienfr, I've been able to understand what causes this massive memory leak when using `PhpArrayAdapter`:  When tests run, a new kernel is booted for each test case. This means a new instance of `PhpArrayAdapter` is created, which means it loads its state again and again using `include` for e.g. `annotations.php` in this example. The first obvious thing is that we see this doing `compile::*`: this means PHP is parsing the same file again and again. But shouldn't opcache prevent this? Well, it's disabled by default because `opcache.enable_cli=0`. To prove the point, here is a comparison with the same tests run with `php -dopcache.enable_cli=1`. The comparison is swapped, but you'll get it:  But that's not over: because of https://bugs.php.net/76982 (see #32236 also), we still have a memory leak when the included file contains closures. And this one does. This PR fixes the issue by storing the return value of the include statement into a static property. This fits the caching model of `PhpArrayAdapter`: it's a read-only storage for system caches - i.e. its content is immutable. Commits ------- 4194c4c [Cache] fix memory leak when using PhpArrayAdapter
|
@nicolas-grekas I confirm this fix the memory issue I had in my tests! Before I had this with the
I now have this, without the
Congrats! |
nicolas-grekas
added a commit
that referenced
this pull request
Dec 10, 2019
…s-grekas) This PR was merged into the 4.3 branch. Discussion ---------- [Cache] fix memory leak when using PhpFilesAdapter | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #34687 | License | MIT | Doc PR | - Similar to #34839 but for `PhpFilesAdapter`, as the "appendOnly" mode is a v4-only feature. Commits ------- 0b46226 [Cache] fix memory leak when using PhpFilesAdapter
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thanks to @adrienfr, I've been able to understand what causes this massive memory leak when using
PhpArrayAdapter:When tests run, a new kernel is booted for each test case. This means a new instance of
PhpArrayAdapteris created, which means it loads its state again and again usingincludefor e.g.annotations.phpin this example.The first obvious thing is that we see this doing
compile::*: this means PHP is parsing the same file again and again. But shouldn't opcache prevent this? Well, it's disabled by default becauseopcache.enable_cli=0. To prove the point, here is a comparison with the same tests run withphp -dopcache.enable_cli=1. The comparison is swapped, but you'll get it:But that's not over: because of https://bugs.php.net/76982 (see #32236 also), we still have a memory leak when the included file contains closures. And this one does.
This PR fixes the issue by storing the return value of the include statement into a static property. This fits the caching model of
PhpArrayAdapter: it's a read-only storage for system caches - i.e. its content is immutable.