Edit report at https://bugs.php.net/bug.php?id=80341&edit=1
ID: 80341
Updated by: cmb@php.net
Reported by: alex at ndros dot com
Summary: OPCache wasted memory grows rapidly and no restart
after max_wasted_percentage
-Status: Assigned
+Status: Feedback
Type: Bug
Package: opcache
Operating System: Windows 2019
PHP Version: 7.4.12
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Hmm, I still cannot reproduce any of the reported behavior.
> Yes, the files are located in a symlink pointing to an SMB
> share.
This might be reason for the misbehavior. Could you please
post what
fsutil reparsePoint query <path>
reports for the symlink and the SMB share?
Could you also please check whether realpath() resolves any of the
files on the SMB share correctly, and also what filemtime() and
stat()['mtime'] reports? I'm not so much interested in the exact
timestamps, but rather whether these are "in the future" what could
explain the premature updates.
Previous Comments:
------------------------------------------------------------------------
[2020-11-09 16:05:02] cmb@php.net
Thanks for the swift reply!
I'll have a closer look.
------------------------------------------------------------------------
[2020-11-09 14:36:21] alex at ndros dot com
Hi there,
Yes, I'm using php-7.4.12-nts-Win32-vc15-x64.zip
We're using a load balance with multiple IIS server. Yes, the files are located in a symlink
pointing to an SMB share.
But it seems that I have solved the problem with the wasted memory. I switched off
opcache.file_cache and now after 12 hours the wasted memory is at 0%. So whatever it was, it was
somehow related to the file_cache.
However, the problem that Opcache not reseting after opcache.max_wasted_percentage is reached still
remains. I did several tests for this, and it never resets when the value was reached.
------------------------------------------------------------------------
[2020-11-09 10:27:30] cmb@php.net
> I run PHP 7.4.12 [â¦]
Assuming it is about a build from windows.php.net, which one
exactly? php-7.4.12-nts-Win32-vc15-x64.zip?
> I can verify this be updating .php files and the changes show up
> instantly (where normally they take 90 seconds or less, based on
> my opcache.revalidate_freq).
Are these files stored on some file share, or are they somehow
linked (e.g. behind a junction)?
Is there any possibly relevant info in the OPcache error log?
------------------------------------------------------------------------
[2020-11-09 00:10:53] alex at ndros dot com
Also, the default opcache.max_wasted_percentage of 5% does not seem to work. Nothing happens when 5%
is exceeded.
------------------------------------------------------------------------
[2020-11-09 00:09:28] alex at ndros dot com
Description:
------------
I run PHP 7.4.12 on a Windows 2019 IIS10 server.
The wasted memory value in PHP Opcache grows rapidly, fills up my entire 2GB allocated to Opcache,
and then opcache stops working.
For example, these are the statistics after 30mins since the last webserver reset:
total memory: 2.00GB
used memory: 89.00MB
free memory: 1.66GB
wasted memory: 261.36MB (12.76%)
And these are my settings:
opcache.memory_consumption=2048
opcache.cache_id=oc1
opcache.error_log="D:\temp\php\opcache_errors.log"
opcache.validate_timestamps=1
opcache.revalidate_freq=90
opcache.interned_strings_buffer=32
opcache.save_comments=0
opcache.max_file_size=0
opcache.file_update_protection=0
opcache.file_cache_consistency_checks=0
opcache.file_cache="D:\temp\php\opcache_filecache"
opcache.max_accelerated_files=100000
If I leave it to run more time, the wasted memory fills up my entire 2GB allocated to Opcache, and
opcache will simply stop to work. I can verify this be updating .php files and the changes show up
instantly (where normally they take 90 seconds or less, based on my opcache.revalidate_freq).
Thanks
Alex
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=80341&edit=1