Edit report at https://bugs.php.net/bug.php?id=78147&edit=1
ID: 78147
Updated by: cmb@php.net
Reported by: mario dot bandeira at cronobandeira dot com
Summary: Memory leak after upgrade to 7.2.19
-Status: Open
+Status: Feedback
Type: Bug
Package: opcache
Operating System: Windows Server 2016 Standard
PHP Version: 7.2.19
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
I assume that this is a duplicate of bug #78103, which apparently
is fixed as of PHP 7.2.20, or can anybody still reproduce this
issue?
Previous Comments:
------------------------------------------------------------------------
[2019-09-17 19:34:56] john at onatlas dot com
update from my prior report...
php 7.2.21 64 bit stable in my environment
Steps to resolve
ONE switch to 64 bit php from 32bit
TWO disable extension wincache 2.0.0.8, which never had an official build for php 7.2
THREE use mmap_base as mentioned online for Windows
FOUR restart Windows
A windows server restart was needed once these were applied to php.ini. Even App Pool recycle
resulted in lingering failures (I have 5 app pools with php).
These directives related to opcache in php.ini now
opcache.error_log = "D:\php72x64\tmp\opcache.log"
opcache.file_cache="D:\php72x64\tmp\opcache"
opcache.log_verbosity_level=2
opcache.mmap_base=0x20000000
Bonus, during unstable trial and error time frame, having the file_cache configured prevented a 500
status, instead logging "Sep 10 16:19:22 2019 (6692): Warning Base address marks unusable
memory region (fall-back to file cache)"
mmap_base and the removal of wincache seemed to be the primary fix, may try wincache again in future
php build, if MS releases official extension
------------------------------------------------------------------------
[2019-08-02 04:21:22] john at onatlas dot com
very similar experience!
two Windows 2008R2 x64 servers
Under Zend Server 2018.0.3 with php 7.2.15 32bit, opcache enabled, no errors, very stable.
Upgrade to php 7.2.20 32bit (no more Zend Server), still with opcache enabled, on same two windows
servers.
After production server runs OK for ~10-20 minutes in load balancer, I get errors from pages that
connect to remote servers, maybe 1% of requests.
Most common failures...
- Uncaught Exception cURL error 6: getaddrinfo() thread failed to start (connect to remote queue
service)
- [Microsoft][ODBC Driver 17 for SQL Server]SQL Server Network Interfaces: Not enough storage is
available to process this command.
- fsockopen(): unable to connect to searchengine.local:8080 (An operation on a socket could not be
performed because the system lacked sufficient buffer space or because a queue was full.
When I disable opcache in php 7.2.20, errors stop, but pages are too slow!
Tried these variety of opcache directives
ONE
opcache.enable=1
TWO
opcache.optimization_level=0xffffffff
THREE
opcache.optimization_level=0xffffffff
opcache.mmap_base=0x20000000
FOUR
opcache.mmap_base=0x20000000
When opcache enabled, with all directives tried, random errors start on server in 10-20 minutes
------------------------------------------------------------------------
[2019-07-04 16:39:35] kris at accuwebhosting dot com
Same issue with PHP 7.2.19 (FastCGI), Windows 2016 server and Plesk.
------------------------------------------------------------------------
[2019-06-12 16:49:31] mendel at spotlightdesign dot com
PHP error log:
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate
7810770492979178392 bytes) ... (That's a lot of bytes!!!, Much more than in the other reports
posted).
Possibly related to https://bugs.php.net/bug.php?id=78103 (as posted by
mario on that report).
------------------------------------------------------------------------
[2019-06-12 15:43:17] mario dot bandeira at cronobandeira dot com
I have made some tests and the problem is on with or without the opcache enabled for the subdomain.
The subdomain (cnr.cronobandeira.com) that originally had the problem (with php 7.2.19) is now
running php 7.1.30 without any issues.
------------------------------------------------------------------------
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=78147
--
Edit this bug report at https://bugs.php.net/bug.php?id=78147&edit=1