Bug #80341 [Fbk->NoF]: OPCache wasted memory grows rapidly and no restart after max_wasted_percentage

Edit report at https://bugs.php.net/bug.php?id=80341&edit=1 ID: 80341 Updated by: php-bugs@lists.php.net Reported by: alex at ndros dot com Summary: OPCache wasted memory grows rapidly and no restart after max_wasted_percentage -Status: Feedback +Status: No Feedback Type: Bug Package: opcache Operating System: Windows 2019 PHP Version: 7.4.12 Assigned To: cmb Private report: N New Comment: No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. Previous Comments: ------------------------------------------------------------------------ [2021-12-01 17:30:14] cmb@php.net Since PHP-7.4 won't receive further regular bug fixes, is this still an issue for you with PHP 8.0 or 8.1? ------------------------------------------------------------------------ [2020-11-17 16:57:47] cmb@php.net > However, the problem that opcache will not reset after the > max_wasted_percentage value is reached still remains. It is important to note that a restart is only triggered, if there actually is not enough free memory (i.e. some SHM allocation failed). I've just updated the manual accordingly[1]. That said, for me OPcache restarts in that case. [1] <http://svn.php.net/viewvc?view=revision&revision=351415> ------------------------------------------------------------------------ [2020-11-17 10:51:09] cmb@php.net > […] , not regarding opcache.force_restart_timeout appears to be > bug. Well, on a closer look, it doesn't. While on non Windows platforms, all processes which share an OPcache instance are forked childs of the same process, on Windows arbitrary processes may share an OPcache instance, so forcefully terminating these processes may not even be possible. At least, there is currently no provision to track the relevant processes, so for now this is a documentation problem, fixed with <http://svn.php.net/viewvc?view=revision&revision=351404>. ------------------------------------------------------------------------ [2020-11-13 15:48:17] cmb@php.net There are general issues regarding OPcache restarts on Windows. A long running process attached to the same OPcache instance apparently completely blocks restarts, even if opcache.force_restart_timeout has expired. While a long running request should probably use its own OPcache instance, not regarding opcache.force_restart_timeout appears to be bug. And if opcache.file_cache is enabled, restarts take considerable time between the schedule and the actual restart, contrary to opcache.file_cache being disabled. > I cannot publish much more information here. Okay, but actually I'm only interested in the "Reparse Tag Value" of the SMB share, since we do not support arbitrary reparse tags, and this might explain some issues. ------------------------------------------------------------------------ [2020-11-12 15:33:10] alex at ndros dot com Hi there, We're using SMB3. The network connection to the SMB share is perfectly stable. The reason for the pre-mature updates was that OPcache stopped running altogether. All opcache statistics froze. After wasted_memory filled my entire 2GB allocation, Opcache stopped running. The wasted memory problem is gone since we removed filecache. Right now, Opcache is much healthier: total memory: 256.00MB used memory: 92.91MB free memory: 163.09MB wasted memory: 0.00b (0%) number of cached files: 3,229 number of hits: 1,623,566,737 number of misses: 16,133 blacklist misses: 1,732,646 number of cached keys: 5,683 max cached keys: 130,987 interned strings usage buffer size: 24.00MB used memory: 7.59MB free memory: 16.41MB number of strings: 109,680 However, the problem that opcache will not reset after the max_wasted_percentage value is reached still remains. The output of that command is: fsutil reparsePoint query D:\inetpub\wwwroot Reparse Tag Value : 0xa000000c Tag value: Microsoft Tag value: Name Surrogate Tag value: Symbolic Link Reparse Data Length: 0x00000068 Reparse Data: 0000: 28 00 34 00 00 00 28 00 00 00 00 00 5c 00 5c 00 (.4...(.....\.\. 0010: 31 00 30 00 2e 00 31 00 2e 00 31 00 2e 00 31 00 1.0...1...1...1. 0020: 30 00 30 00 5c 00 77 00 77 00 77 00 72 00 6f 00 0.0.\.w.w.w.r.o. 0030: 6f 00 74 00 5c 00 3f 00 3f 00 5c 00 55 00 4e 00 o.t.\.?.?.\.U.N. 0040: 43 00 5c 00 31 00 30 00 2e 00 31 00 2e 00 31 00 C.\.1.0...1...1. 0050: 2e 00 31 00 30 00 30 00 5c 00 77 00 77 00 77 00 ..1.0.0.\.w.w.w. 0060: 72 00 6f 00 6f 00 74 00 r.o.o.t. I cannot publish much more information here. If you want, I can give you access to a VM in the load balance, with the initial settings that caused the problem so that you can debug. Thanks Alex ------------------------------------------------------------------------ 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