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: 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:
Also, which version of SMB is in use there? Version 1 is insecure
and has other known issues, so you should use at least v2 or
better v3.
Furthermore, I'm assuming that the network connection to that SMB
share is very stable; otherwise an unstable connection might be
the root cause for "arbitrary" issues in this regard. And likely,
you are better of deploying all the PHP files to the individual
machines instead of hosting them on an SMB share, anyway.
Previous Comments:
------------------------------------------------------------------------
[2020-11-11 16:13:20] cmb@php.net
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.
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=80341
--
Edit this bug report at https://bugs.php.net/bug.php?id=80341&edit=1