How to configure PHP OPcache memory

Undersized OPcache shared memory forces PHP workers to evict cached bytecode sooner, rebuild scripts more often, and spend extra CPU on work that should stay in memory between requests. Tuning the cache size matters most on busy sites, large frameworks, and hosts where several applications share the same OPcache instance.

The main sizing directives are opcache.memory_consumption for bytecode storage, opcache.interned_strings_buffer for deduplicated strings, and opcache.max_accelerated_files for the script hash table. The PHP manual keeps all three at INI_SYSTEM scope, so the effective values must come from the loaded SAPI configuration, a later .ini drop-in, PHP-FPM pool overrides, or web-server FastCGI parameters rather than from application code.

Current distro packages do not all place those directives in the same file. On current Ubuntu and Debian packages, the shared /etc/php/<version>/mods-available/opcache.ini file commonly loads only the extension while the default sizing directives stay commented in the SAPI-specific php.ini. The safe workflow is to query the runtime that serves requests, find the last place that defines the settings, change only that active file, test the runtime configuration, and then reload the service.

Related: How to enable PHP OPcache on Ubuntu or Debian

Steps to configure PHP OPcache memory:

  1. Check the current OPcache memory values in the runtime that serves the application. 
    $ php-fpm8.3 -i | grep -E 'Loaded Configuration File|^opcache.memory_consumption =>|^opcache.interned_strings_buffer =>|^opcache.max_accelerated_files =>'
Loaded Configuration File => /etc/php/8.3/fpm/php.ini
opcache.interned_strings_buffer => 8 => 8
opcache.max_accelerated_files => 10000 => 10000
opcache.memory_consumption => 128 => 128

    Use the matching binary name such as php-fpm or php-fpm8.4 when the installed package uses a different branch. If Apache mod_php, per-pool php_admin_value[] entries, or web-server PHP_ADMIN_VALUE headers can override the same directives, confirm the final values from a temporary request handled by that site instead of relying on the binary alone.

  2. Search the active configuration tree for every place that defines the OPcache sizing directives before editing anything. 
    $ sudo grep -REn '^[;[:space:]]*opcache\.(memory_consumption|interned_strings_buffer|max_accelerated_files)[[:space:]]*=|php_(admin_)?value\[(opcache.memory_consumption|opcache.interned_strings_buffer|opcache.max_accelerated_files)\]' /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/conf.d /etc/php/8.3/mods-available /etc/php/8.3/fpm/pool.d 2>/dev/null
/etc/php/8.3/fpm/php.ini:1788:;opcache.memory_consumption=128
/etc/php/8.3/fpm/php.ini:1791:;opcache.interned_strings_buffer=8
/etc/php/8.3/fpm/php.ini:1795:;opcache.max_accelerated_files=10000

    Current Ubuntu and Debian packages commonly keep these defaults commented in the SAPI-specific /etc/php/<version>/<sapi>/php.ini file, while /etc/php/<version>/mods-available/opcache.ini usually contains only the extension load and JIT settings. A later .ini drop-in, PHP-FPM pool php_admin_value[] entry, or web-server override still wins if one is present. On Fedora, RHEL, Rocky, AlmaLinux, or CentOS Stream, search /etc/php.ini, /etc/php.d, and /etc/php-fpm.d instead.

    Related: How to find PHP configuration files

  3. Create a backup of the file that currently determines the effective OPcache memory values. 
    $ sudo cp /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak-$(date +%Y%m%d%H%M%S)

    Keep the backup until the runtime reports the new values after the reload. A typo in a shared or SAPI-wide PHP configuration file can affect every application that uses that runtime.

  4. Open the active configuration file in a text editor. 
    $ sudoedit /etc/php/8.3/fpm/php.ini

    Edit the last-loaded file found in the search step when the effective values come from a later .ini drop-in or a pool-specific override instead of the main php.ini. Uncomment the existing directives when they are already present instead of adding duplicate entries earlier in the file.

  5. Set OPcache memory values that fit the application footprint and script count. 
    opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000

    opcache.memory_consumption cannot be set below 8 MB. opcache.max_accelerated_files is clamped to 200 through 1000000, and the runtime rounds the requested value up to the next supported prime-sized hash table.

    Raise opcache.memory_consumption when the cache stays short on free memory after normal traffic warms it. Raise opcache.max_accelerated_files when the number of cached keys approaches the maximum or the cache records hash restarts, and raise opcache.interned_strings_buffer when interned string free space stays tight.

  6. Test the PHP-FPM configuration before reloading the service. 
    $ sudo php-fpm8.3 -t
[26-Mar-2026 06:12:41] NOTICE: configuration file /etc/php/8.3/fpm/php-fpm.conf test is successful

    Use the matching binary for the installed package, such as php-fpm on RHEL-family hosts. If Apache mod_php serves the site, validate the surrounding web-server configuration before reloading it.

    Do not reload the service until the configuration test succeeds.

  7. Reload the runtime that serves PHP requests so new workers pick up the updated OPcache limits. 
    $ sudo systemctl reload php8.3-fpm

    Reload Apache instead with sudo systemctl reload apache2 or sudo systemctl reload httpd when PHP runs as an Apache module. On Ubuntu and Debian, the PHP-FPM unit is usually versioned such as php8.3-fpm, while RHEL-family systems commonly use php-fpm.

    Related: How to manage the PHP-FPM service in Linux
    Related: How to manage the Apache web server service

  8. Verify the new OPcache limits from the same runtime after the reload. 
    $ php-fpm8.3 -i | grep -E '^opcache.memory_consumption =>|^opcache.interned_strings_buffer =>|^opcache.max_accelerated_files =>'
opcache.interned_strings_buffer => 16 => 16
opcache.max_accelerated_files => 20000 => 20000
opcache.memory_consumption => 256 => 256

    If a request-handled probe is available, check opcache_get_status(false) after normal traffic warms the cache and review memory_usage.free_memory, interned_strings_usage.free_memory, opcache_statistics.num_cached_keys, opcache_statistics.max_cached_keys, oom_restarts, and hash_restarts before deciding to increase the limits again. A fresh reload starts with an empty cache, so immediate post-reload headroom is only a baseline.

    Related: How to find PHP configuration files