80 WordPress sites, one OPcache: eleven days in production

Case study · PHP 8.4 · OPcache

This article follows up on 80 WordPress sites, one OPcache

Vitalyn · November 2026 · PHP 8.4.27, opcache-dedup patch

What's running

The server hosts 74 PHP-FPM pools, spread across several PHP versions. Each site has its own Linux user and pool. Each PHP version has a single FPM master, and therefore a single OPcache shared by all its pools. Version 8.4 carries 52 of them: that is the one that got dedup.

The PHP packages are the usual distribution ones, rebuilt with the patch. Nothing changes as long as the directive is absent. Enabling it takes one file, loaded after the package's OPcache configuration:

; /etc/php/8.4/fpm/conf.d/99-opcache-dedup.ini
opcache.enable_dedup = 1
opcache.jit = disable

The rollout happened in two stages: one week on the development server (dedup enabled on several versions since October 22, no incidents), then production, on October 29 at 9:34 am, on version 8.4 only.

Memory: -43%, same as the bench

Two independent measurements give the same number.

From the outside. A probe reads the resident part of the 8.4 master's OPcache segment every five minutes, without going through PHP. Before October 29, it hovered between 4.3 and 4.5 GB. With dedup, same configuration, same sites: 2.5 GB. That is -43%.

From the inside. opcache_get_status() counts the memory that dedup avoided copying. Added to the memory used, it gives what the same content would take up without the patch: today 3.1 GB used and 2.3 GB saved, i.e. 5.4 GB without dedup. The gain is 43%, and above all, without the patch, this cache would no longer fit in its 5 GB: it would fill up every time it warmed up.

The bench predicted -46.5% on 80 copies of the same stack. Production mixes more WordPress and plugin versions: 82.5% of compiled functions find an identical block already stored, and the gain stays in the same range.

Stability: no crash attributable to the patch

In eleven days, no worker died from SIGSEGV, SIGBUS or SIGABRT, on any version. The logs from the previous weeks, without dedup, contain three, between September 28 and October 22.

The server did, however, go through two out-of-memory episodes, on October 30 and November 4, where the kernel killed MariaDB and PHP workers. We analyzed them in detail, because suspicion is legitimate right after a production rollout:

• OPcache memory stayed stable during both episodes (between 2.6 and 2.9 GB),
• what grew was the workers' private memory: 196 8.4 workers at about 230 MB each, across 52 pools each allowed to scale up to 32 workers,
• the trend predated dedup, fed by the migration of sites to 8.4.

Dedup reduces shared memory. It does not touch each worker's per-request memory. This is a pool sizing problem, which the graphs described below now let us fix pool by pool.

The graphs: what they revealed

To follow the production rollout, we needed to see OPcache and the pools continuously, version by version, without exposing anything on the web.

• OPcache. A small PHP script, placed outside the sites, returns opcache_get_status() in Prometheus format. It cannot be reached over HTTP: a probe calls it every minute directly over FastCGI, on the socket of one pool per version, just as the web server would. It rejects any request that comes through a web server.
• Pools. The same probe reads each pool's status page (pm.status_path, also over direct FastCGI) and its workers' memory from /proc.
• Dashboards. Everything goes into our monitoring, with one OPcache dashboard per version, one PHP-FPM dashboard per pool, and four alerts: cache full, requests waiting for a worker, pool at its limit, high PHP memory.

The "OPcache full" alert fired within an hour of going live.

1. The cache was full, but not of memory

The OPcache dashboard showed version 8.4 as "full" with 2.7 GB free out of 5. The culprits: two limits that dedup had pushed ahead of memory:

• the key table: 262,237 entries out of 262,237. It is sized from opcache.max_accelerated_files, then set to 200,000,
• the interned strings buffer: 64 MB out of 64.

Once either limit is reached, OPcache stops caching new scripts: they are recompiled on every request. We raised max_accelerated_files to 1,000,000 and interned_strings_buffer to 256 MB on November 5. Four days later, the key table is at 32%, but interned strings are already at 91%: they will be the next limit.

The lesson applies to any dedup rollout. By freeing memory, it lets more scripts be cached, and OPcache's other limits come sooner. They need to be sized together: keys, interned strings and memory.

2. Plugins flush the cache of every site

The memory graph shows drops at irregular intervals: seven full flushes of the 8.4 cache in four days, two of them around 3 am. They are neither restarts nor saturation: the manual_restarts counter attributes them to calls to opcache_reset().

This function appears in the code of several common WordPress plugins, for caching or remote management, which may call it after an update or after flushing their own cache. On a server where one master serves 52 sites, an action on a single site flushes the cache of the other 51, which recompile everything in the following minutes.

This behavior has nothing to do with dedup: it is stock OPcache. So is the fix: opcache.restrict_api, which restricts the OPcache API to an administration directory. We were already recommending it to shut off enumeration of other sites' scripts (part 1). Production shows it also protects availability.

3. The dedup table has headroom

The table referencing shared blocks holds 404,109 entries out of 786,432 usable (51%), i.e. 1.8 unique blocks per cached script. Its size depends on max_accelerated_files and caps at 2²⁰ slots of 32 bytes, i.e. 32 MB. On the development server, which is smaller, it had reached 93%. A full table breaks nothing: new blocks simply stop being shared. But this finding argues for a configurable size, a question we will raise with the maintainers.

4. Sizing pools from measurements

The PHP-FPM dashboard gives, for each pool, the peak of active workers, how many times the limit was hit, and the real memory (PSS) of its workers. Of the server's 74 pools, all allowed to scale up to 32 workers, 15 never used more than two over two days of data, and only five hit the limit. The uniform setting let every small site reserve enough to bring the server down. This is the work in progress to put an end to the out-of-memory episodes.

What production changes in the proposal

• The gain holds outside the bench: -43% on a real, heterogeneous fleet, measured two ways.
• No crashes in eleven days, and both server incidents are explained without the patch.
• The documentation should stress OPcache's other limits: max_accelerated_files and interned_strings_buffer become the bottleneck before memory does.
• opcache.restrict_api is essential as soon as several sites share a master, dedup or not.
• The size of the dedup table should be configurable, or sized from memory rather than from the number of scripts.
• The exposed counters are enough for operations: memory saved, table fill and sharing can all be tracked with opcache_get_status(), no dedicated tool needed.

What's next

Dedup stays enabled on 8.4 and will be extended to 8.2, 8.3 and 8.5 once the pools are resized. On the PHP side, the patch is ready for the development branch. We are proposing it to the maintainers, with these production numbers on top of the bench ones.

Measurements from October 21 to November 9, 2026 on our production server (PHP 8.4.27, 52 pools).