In PHP, how do you size opcache.memory_consumption and opcache.max_accelerated_files, and how do you tell that OPcache is full?

## Two separate limits OPcache stores compiled scripts in one shared memory segment and finds them through a hash table keyed by path. Each has its own limit, and either can fill first. | Directive | Default | Limits | |---|---|---| | `opcache.memory_consumption` | `128` (MB) | total shared memory for compiled scripts | | `opcache.interned_strings_buffer` | `8` (MB) | the part of that memory used for shared strings | | `opcache.max_accelerated_files` | `10000` | number of script keys in the hash table | | `opcache.max_wasted_percentage` | `5` | wasted share that allows an automatic restart | All four are `PHP_INI_SYSTEM`: they are read when the server starts, and every PHP-FPM pool under one master shares the same segment. PHP 8.5 reports an attempt to change `memory_consumption` once the segment exists, such as a per-pool override, instead of silently ignoring it. ## Sizing max_accelerated_files The value is not used as written. OPcache picks the first number in a fixed set of primes — `223, 463, 983, 1979, 3907, 7963, 16229, 32531, 65407, 130987, 262237, 524521, 1048793` — that is at least the configured value, within a minimum of `200` and a maximum of `1000000`. The default of `10000` therefore gives `16229` slots. To size it: 1. Count the PHP files the application can load, including `vendor/` and generated code: `find . -name '*.php' | wc -l`. 2. Add headroom, because one file can occupy more than one key (a script reached through different paths) and new releases add files. 3. Choose a value that lands on the next prime comfortably above the total. Applications with large dependency trees routinely exceed the default. ## Sizing memory_consumption Memory depends on how much code is compiled, not on traffic. Start from the default, let a production server warm up, then read `memory_usage` from `opcache_get_status()`: - `used_memory`: what cached scripts occupy. - `free_memory`: what is left. - `wasted_memory`: space held by outdated entries, for example scripts replaced after a file changed or was invalidated. Set the limit so that `free_memory` keeps a healthy margin after a full warm-up. If `interned_strings_usage.free_memory` approaches zero, raise `opcache.interned_strings_buffer` too; once it overflows, OPcache logs "Interned string buffer overflow" and stops sharing new strings. ## What happens when it is full When OPcache cannot store a new script — out of memory or out of hash slots — it marks the cache as full and **compiles that script for the current request without caching it**. Every request that needs it pays the compile cost again. A restart of the cache is scheduled only when wasted memory has reached `opcache.max_wasted_percentage`; otherwise the cache simply stays full. The symptoms, all visible in `opcache_get_status()`: - `cache_full` is `true`. - `opcache_statistics.num_cached_keys` is at `max_cached_keys`. - `opcache_statistics.oom_restarts` or `hash_restarts` keeps increasing: each is a full flush followed by a recompile burst. - `opcache_statistics.opcache_hit_rate` drops below the high-90s you see on a healthy server. ## A worked sizing example Suppose a service ships about 21 000 PHP files including `vendor/`, and a warmed-up server reports roughly 150 MB of `used_memory` with the default settings and a non-zero `hash_restarts` counter. 1. The default `max_accelerated_files=10000` gives 16 229 slots — fewer than the files the application can load, which explains the hash restarts. 2. Setting `max_accelerated_files=30000` rounds up to 32 531 slots, leaving room for growth and for files reached through more than one path. 3. With 150 MB used against the default 128 MB, the memory limit is also too low; setting `memory_consumption=256` leaves a comfortable margin. 4. After the change, restart PHP-FPM (these settings are read only at startup), let traffic warm the cache, and confirm that `cache_full` stays `false` and both restart counters stop moving. The numbers are illustrative; the method — count files, measure warmed usage, add headroom, verify — is what carries over. ## A monitoring habit Export those fields to your metrics system from a small script that runs inside the PHP-FPM pool — a CLI call sees a different cache. Alert on `cache_full`, on any growth of `oom_restarts` or `hash_restarts`, and on a sustained drop in hit rate. After each major dependency upgrade, recheck the file count against `max_cached_keys`.