-
Notifications
You must be signed in to change notification settings - Fork 7.9k
memory usage increasing when using opcache.enable_cli and opcache.file_cache_only #9812
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
related PR #7563 asserting the non-leaking behavour with configurations where possible, I would be happy if someone can merge it and fix for every configuration of course highly welcomed |
Pretty sure there was a bug report and analysis for this issue on the old bug tracker, but I can't find it. This issue should be unrelated to the dynamic defs issue linked above. The problem (I believe) is that file cache loads the cached file into an arena allocation, and usually that arena allocation gets discarded after moving the contents to SHM. Of course, this does not happen if file_cache_only is used. In that case we end up performing the arena allocation on every include, without ever freeing it. |
I think this is about https://bugs.php.net/78076. |
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
We recently enabled `opcache.enable_cli` so Cavalcade Runner now has the opcache enabled. This is a bug, it turns out in the opcache whereby including files over and over again will lead to a memory leak. See php/php-src#9812 for details. This bug causes a very large memory leak in Cavalcade Runner because we naively re-init the Cloudwatchclient on every call to put_metric_data() etc. So, it makes sense to only create the cloudwatch client once. THis should also drastically reduce the impact of the PHP bug.
Description
The below script using opcache.enable_cli=1 and opcache.file_cache_only=1 causes the PHP memory usage to continue to increase. If I disable file_cache_only, then the memory usage remains constant. I was able to reproduce in PHP 8.1, 8.2, and 7.4.
To reproduce, set-up scripts test.php and test2.php as listed below, create an empty directory /tmp/opcache, and then run:
When I run the above, the value of memory_get_usage() continues to increase. If I remove the line for "opcache.file_cache_only=1", then memory_get_usage() remains constant.
If it doesn't happen the 1st time, then try running it a 2nd time.
Can you please check why the memory usage continues to grow in this scenario?
Thanks for your help.
test.php:
test2.php:
PHP Version
PHP 8.1.11
Operating System
AlmaLinux 8
The text was updated successfully, but these errors were encountered: