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

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