Repository navigation
opcache.interned_strings_buffer = 4096 is ignored and using default (PHP8) + segfault (PHP7+PHP5) #13598
Description
Description
Hi,
if I set opcache.interned_strings_buffer = 2048 or other lower value everything is fine. (working well)
If I set opcache.interned_strings_buffer = 4096 and reload PHP FPM I got problem.
Two cases:
PHP FPM 8.3.3 - ignoring value and set for default value 8 (no error log info in syslog or php fpm log)
PHP FPM 5.6.40 (PHP 7.x is segfault as well) - segfault (I know, obsolete version, only for context - if I set lower value, no problem here) - here is the log from syslog php 5.6
Mar 5 14:06:03 s08 kernel: [5656531.610602] show_signal_msg: 6 callbacks suppressed
Mar 5 14:06:03 s08 kernel: [5656531.610604] php-fpm5.6[924861]: segfault at 30 ip 00005609add607d1 sp 00007ffdb3329e30 error 4 in php-fpm5.6[5609adbc6000+242000]
Mar 5 14:06:03 s08 kernel: [5656531.610612] Code: 19 48 01 c3 48 89 d8 48 8d 4a 01 48 c1 e0 05 48 01 d8 48 0f be 1a 48 01 c3 48 89 d8 48 c1 e0 05 48 01 d8 48 0f be 19 48 01 c3 <48> 8b 47 30 89 da 23 57 04 48 8b 2c d0 48 85 ed 74 5d 45 89 ef eb
Environment:
Ubuntu 22 LTS
physical memory 1TB
opcache.memory_consumption = 25000
I didn't have oportunity to test PHP 7.x but in every PHP version it's not working. 2 possible options:
- use default 8
- segfault
Do you need more informations?
Thank you.
PHP Version
8.3.3
Operating System
Ubuntu 22.04 LTS
Activity
devnexen commentedon Mar 5, 2024
Juste a note here about actively supported PHP versions.
damianwadley commentedon Mar 5, 2024
Are you sure there's no messages in the FPM logs? And that you have those logs set up properly, of course?
If php-fpm is disregarding your request for 4 GB (the setting is measured in MBs) of interned_strings_buffer then it should write a warning to the FPM log saying
where the first number is the maximum value permitted - which is almost certainly going to be less than 4096.
@devnexen: You removed Needs Triage but didn't substitute another Status label. Was that intentional? There should probably always be a Status assigned, be that Needs Triage or Verified or whatever.
devnexen commentedon Mar 5, 2024
I admit I did, I thought assigning PHP component label was sufficient, will remember for next time, cheers.
arnaud-lb commentedon Mar 6, 2024
Opcache has its own logging system controlled by
opcache.log_verbosity_levelandopcache.error_log. Withopcache.log_verbosity_level=3, we can see the following being logged:This warning was added in 8.2: #9260. In hindsight, this should probably be an error.
ShaiMagal commentedon Mar 9, 2024
@arnaud-lb Yea, it is good catch, totally coresponding our situation (#9260).
We see in logs now (we try 9999 only for test):
"Warning opcache.interned_strings_buffer must be less than or equal to 4095, 9999 given."
DETAILED TEST RESULTS:
PHP 8.3 - 2048 = working well
PHP 8.3 - 4095 = working well
PHP 8.3 - 4096 = automatically set to 8
PHP 7.4 - 2048 - working well
PHP 7.4 - 4095 - segfault
PHP 7.4 - 4096 - segfault
PHP 5.6 - 2048 - working well
PHP 5.6 - 4095 - segfault
PHP 5.6 - 4096 - segfault
We have very busy servers, with 2TB+ memory each and we "need" this value higher, for example 10GB in reality.
So, what are options, how to solve this problem? I think, 4095 "hardcoded" is max value if I understand this well?
Or we miss something?
ShaiMagal commentedon Mar 9, 2024
@devnexen I know, 5.6 is obsolete - I use it only for compare, we care about actual versions (PHP 8.1+) of course :)
[-]opcache.interned_strings_buffer = 4096 is ignored and using default (PHP8) + segfault (PHP5)[/-][+]opcache.interned_strings_buffer = 4096 is ignored and using default (PHP8) + segfault (PHP7+PHP5)[/+]arnaud-lb commentedon Mar 9, 2024
The limitation comes from the fact we use 32bit offsets to the interned strings buffer. It should be possible to remove this limitation by switching to 64bit offsets (which would increase the memory usage), or by partitioning the buffer internally.
ShaiMagal commentedon Mar 9, 2024
OK, understand. So this isn't bug, but "feature", yea?
Btw, do you know why we have segfault for this settings?
PHP 7.4 - 4095 - segfault (2048 working)
(I know, PHP 7.4 isn't supported, but more than 50% of our customers have this version already)
Thank you.
arnaud-lb commentedon Mar 11, 2024
Yes I consider this a feature request because it works as indented.
7.4 fails earlier because it uses different types internally.
After looking at it, it appears that we could increase the limit to 32GB in 8.4 without adding memory overhead or increasing complexity, by taking profit of the fact that offsets are 8-bytes aligned.
BTW, could you describe your use-case? Do you know how many interned strings you have in 4GB? Are you running a shared hosting?
arnaud-lb commentedon Mar 15, 2024
@ShaiMagal could you check if #13676 helps?
ShaiMagal commentedon Mar 18, 2024
@arnaud-lb We have hundreds customers on every server. Yes, we are webhosting company.
I don't know how many strings is there, because opcache/phpinfo show onl "Used memory" and "Free memory", but not number of strings. So we don't know. We see only this, no more information:
If you know how we can gather more info, let me know and I can ask administrators to do this.
Unfortunatelly, we can't test #13676 , because we don't compile, we are using PPA from Ondrej Sury (packages).
arnaud-lb commentedon Mar 19, 2024
Closing as implemented by #13676
ShaiMagal commentedon Apr 3, 2024
@arnaud-lb thank you! What version of PHP will get this patch?
arnaud-lb commentedon Apr 4, 2024
This will be in 8.4
ShaiMagal commentedon Apr 11, 2024
@arnaud-lb ah, so bad, i hope we can give it to all 8.x to benefit from this feature soon.
Php 8.4 we will benefit from this approximatelly from 2026 :(
Isn't there possibility how to merge this to older versions like 8.1/8.2 as well? If yes, we can benefit from this immediatelly. And not onle we, but all webhostings with same use case :)
arnaud-lb commentedon Apr 12, 2024
This is considered a new feature, or at least not a bug fix, so this can not be merged in a released version. The change should apply cleanly to 8.x however, and the source of the Ondrej Sury packages are available (via
apt source php8.3if you enable the src repository), so it shouldn't be hard to rebuild the packages with one more patch.ShaiMagal commentedon Apr 12, 2024
Understand