The symptom
Pages slow down with no code change, PHP-FPM uses more CPU, and the OPcache hit rate is low. Large WordPress and Laravel sites on one server fill the cache first.
Check it yourself
Read the limits PHP-FPM uses (not the CLI's), and count the PHP files of the sites on that version:
grep -rhE 'opcache\.(memory_consumption|max_accelerated_files)' /etc/php/8.4/fpm/
find /home/*/ -name '*.php' | wc -lThe defaults are 128 MB and 10,000 files. A few WordPress sites with plugins pass 10,000 files easily. The hit rate is in opcache_get_status(), called through PHP-FPM; the CLI has a cache of its own.
How it happens
On a server we run, PHP-FPM had the defaults, 128 MB and 10,000 files. The cache was full, the hit rate was 43%, and a WordPress page took 3.7 seconds. After the change below it took about one second.
The fix
Put the new values in a file of their own in the FPM conf.d, so a package upgrade does not overwrite them:
; /etc/php/8.4/fpm/conf.d/99-opcache.ini
opcache.memory_consumption=384
opcache.max_accelerated_files=60000
opcache.interned_strings_buffer=32sudo php-fpm8.4 -t && sudo systemctl reload php8.4-fpm- Reload, do not restart: a reload lets running requests finish.
- Size it for every site on that PHP version, not one: they share the cache.
- Emptying the cache (an OPcache reset) is not a fix; it fills up again.
How Hostio finds it
The scan reads opcache.memory_consumption and opcache.max_accelerated_files from each PHP-FPM version's ini files, and counts the PHP files under the sites on that version. More files than slots, or more than the memory holds at about 4 KB per file, raises opcache_full, a warning with suggested values: the file count plus 30%, and the memory plus 25%.
The PHP page's Status shows the live hit rate and free memory, read-only, on every plan. Hostio does not edit php.ini for you yet.