Bug #75579 [Csd]: All Interned Strings Free memory used and PHP crashes

From: Date: Fri, 22 Dec 2017 09:26:55 +0000
Subject: Bug #75579 [Csd]: All Interned Strings Free memory used and PHP crashes
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-213239@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=75579&edit=1 ID: 75579 Updated by: nikic@php.net Reported by: post at minhost dot no Summary: All Interned Strings Free memory used and PHP crashes Status: Closed Type: Bug Package: opcache Operating System: CentOS 7.4 PHP Version: 7.1.12 Assigned To: dmitry Block user comment: N Private report: N New Comment: @post at minhost dot no: I've written Anatol to check if this fix can be cherry-picked into the release branches. I think it would be good to do this, as 7.0.27 is going to be the last active support release of PHP 7.0, so if it doesn't go in there, it will probably not be fixed at all. @rhsoft: People have different requirements. Just because your setup does not benefit from the file cache, does not mean that it cannot be beneficial in other configurations. Shared hosting with too many instances to cache everything in SHM sounds like exactly the kind of setup that benefits from the secondary file cache. Previous Comments: ------------------------------------------------------------------------ [2017-12-21 22:47:50] spam2 at rhsoft dot net > @dmitry: I am frustrated to see you applied the patch > to PHP 7.1.14 and not to PHP PHP 7.1.13 the ship for 7.1.13 has already sailed, RC is out and release on 2017/01/04 > We have production servers with a lot of shared hosting clients > running on PHP 7.1.11 and now we will not be able to upgrade > before february 2018 this is not true! first opcache works pretty fine without the file cache at all and we even build PHP with --disable-opcache-file all the time - the SHM cache becomes quickly hot for relevant scripts where it matters second you can apply the patch at your own at build-time, that's the great thing about opensource - with your argumentation we could not run Kernel 4.14 on our Trafficserver while 4.13 on Fedora recieves no longer security updates but we run 4.14.7 in production (https://github.com/apache/trafficserver/issues/2908) ------------------------------------------------------------------------ [2017-12-21 21:50:39] nikic@php.net I've opened bug #75720 to track the other issue that was mentioned in here, regarding the file cache not being populated after SHM runs full. ------------------------------------------------------------------------ [2017-12-21 21:39:17] dmitry@php.net I just committed patch to PHP-7.1 and above branches. I can't commit into branches already detached by release managers. If interned string buffer is overflown, we have to keep extra strings somewhere. In case we load script into SHM, we have to copy these extra strings to SHM as well (or we will crash). Or we can load both script and strings into process memory, and then reload again on each request. ------------------------------------------------------------------------ [2017-12-21 21:22:41] nikic@php.net @dmitry: Yes sorry, I had a logic error. The bailout only happens if both the interned string buffer *and* SHM are full, so there is no problem. ------------------------------------------------------------------------ [2017-12-21 21:16:11] post at minhost dot no @dmitry: My understanding of interned strings is that there should never be saved more interned strings then the limit set in .ini setting: opcache.interned_strings_buffer= So I am confused why it seems you have made it so that it will save interned strings in memory when it exceed the limit we set in .ini setting "opcache.interned_strings_buffer=" Please see: http://php.net/manual/en/opcache.configuration.php Quote from that link: "opcache.interned_strings_buffer The amount of memory used to store interned strings, in megabytes. This configuration directive is ignored in PHP < 5.3.0." So why do you make it so that it stores more interned strings then allocated in this setting? ------------------------------------------------------------------------ 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=75579 -- Edit this bug report at https://bugs.php.net/bug.php?id=75579&edit=1

« previous php.bugs (#213239) next »