opcache_get_status stats wrong when opcache.memory_consumption set in php-fpm pool

[Krinkle]

Description

Bug

When setting php_admin_value[opcache.memory_consumption]=512M via php-fpm pool.conf, the stats reported via opcache_get_status() and phpinfo() will wrongly report ~all your memory as used.

Suggestion

It makes sense that opcache ignores opcache.memory_consumption, because it is scoped to INI_SYSTEM per https://www.php.net/manual/en/ini.list.php. However in that case it should also be ignored by the stats reporting, instead of reporting wrong/inflated memory usage.

A startup warning of sorts might be helpful as well.

Background

Given:

• PHP 8.4.24
• Debian 13 Trixie
• the default opcache.memory_consumption is 128M
• a server with 20 WordPress sites on separate domains, that each consume about 18M memory once one or more of its pages is visited (for a total of ~360M)

By default, we get the following expected stats:

Used memory 134210224 # total=128.00M
Free memory 992 # free = 0.00M
Interned Strings Used memory 5565136 # total=8.0M
Interned Strings Free memory 2823472 # free =2.7M

I tried to increase this in /etc/php/8.4/fpm/pool.d/www.conf:

php_admin_value[opcache.memory_consumption]=512M

After a restart and visiting each site:

Used memory 268388568 # total=255.95M
Free memory 46888 # free = 0.04M

Then:

php_admin_value[opcache.memory_consumption]=960M

Used memory 1006578176 # total=959.94M
Free memory 54784 # free = 0.05M

And eventually:

php_admin_value[opcache.memory_consumption]=2560M

Cache hits 2341
Cache misses 8309
Used memory 2684315432 # total=2559.96M
Free memory 39128 # free = 0.03M
Wasted memory 0
Interned Strings Used memory 5291536 # total=8.0M
Interned Strings Free memory 3097072 # free =2.9M
Cached scripts 2969
Cached keys 3189
Max keys 16229

I mistakenly assumed that each WordPress site must require far more opcache memory than I anticipated. To verify this I used https://github.com/rlerdorf/opcache-status and found that when you add up opcache_get_status()['scripts'], it only explained about 115M, roughly 18M per warmed-up site.

After losing a few hairs at jquery/infrastructure-puppet#109, I eventually stumbled upon this random StackOverflow comment:

David wrote on 12 Feb 2021:

Let me add something I learned today, which wasn't obvious to me and is a consequence of this. I tend to set per-pool PHP options via php_admin_value/php_value etc. in pool configs. If you do this for opcache.memory_consumption or opcache.interned_strings_usage, the actually usable memory won't increase - instead the difference between the respective value in FPM's php.ini and in the pool config will just be added to the used_memory count by opcache_get_status(). This confused me quite a lot and it took me a while to realize that I actually have to change the value in php.ini.

And indeed, moving opcache.memory_consumption from /etc/php/8.4/fpm/pool.d/www.conf to /etc/php/8.4/fpm/conf.d/50-custom.ini solved it.

PHP Version

/usr/sbin/php-fpm8.4 -v
PHP 8.4.24 (fpm-fcgi) (built: Jul 31 2026 05:11:11) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.24, Copyright (c) Zend Technologies
 with Zend OPcache v8.4.24, Copyright (c), by Zend Technologies

Operating System

Debian 13 Trixie

[devnexen]

I think I was able to reproduce it and think, for starter, this change would fix at least the segfault:

--- a/ext/opcache/ZendAccelerator.c
+++ b/ext/opcache/ZendAccelerator.c
@@ -2946,7 +2946,7 @@
 zend_accel_hash_clean(&ZCSG(hash));

- if (ZCG(accel_directives).interned_strings_buffer) {
+ if (ZCSG(interned_strings).saved_top) {
 accel_interned_strings_restore_state();
 }

wdyt @arnaud-lb ?