Why Your Server Suddenly Can't Handle WordPress Anymore

blog_wp_oc.avif

Or: one opcache, 400 megabytes, and how an AI agent helped me debug it.

I run several WordPress servers. Same hardware, same number of sites. Five years ago, a 2 GB RAM server comfortably handled 15 WordPress installs. Today, it struggles with 5. To host 15, you need 4 GB.

The bottleneck isn't MySQL. It isn't Apache. It's OPcache.

What actually changed

WordPress itself got heavier. The 6.6 update alone pushed per-request memory from ~80 MB to 150 MB+ on many setups — a reported, reproducible jump, not a rumor. Plugins got heavier too: page builders, SEO suites, WooCommerce stacks — each one ships thousands of lines of code.

And OPcache has to hold all of it. Every site on the server caches its own plugins, its own theme, its own core files. Five sites with five different plugin stacks means five different sets of files in memory. Fifteen sites? That's a gigabyte of OPcache, easily. It starts above 500 MB before anyone visits a single page.

The week my server started dying

This week, one of my servers started crashing. Not dramatically — just PHP-FPM children dying with SIGSEGV, random OOM kills, and 503s appearing at the worst moments. The server: 2 GB RAM, eight WordPress pools.

The first instinct was to blame the usual suspects: a DDoS, a bad plugin, a hacked site. I was wrong about all three.

How an AI agent helped me fix it

I didn't debug this alone. My Hermes agent (an AI that runs on my servers, reads logs, and executes commands) did the heavy lifting — and it changed how I think about debugging.

It found the real pattern. Instead of guessing, the agent correlated the crash logs with the PHP-FPM configuration. The SIGSEGV kills weren't random — they were memory exhaustion in disguise. One PHP process was trying to allocate 4 GB on a 2 GB server. The smoking gun was in the OPcache statistics, not in the error log.

It did the math. The agent walked me through the OPcache numbers at each setting:

OPcache 128 MB → completely full (32% hit rate)
OPcache 256 MB → completely full (84% hit rate)
OPcache 384 MB → still nearly full (86% hit rate)

One site with a heavy page builder consumed nearly 400 MB of OPcache on its own. Fifteen sites with different plugins? The math writes itself.

It gave me a plan, not just a diagnosis. The fix wasn't "add more RAM and hope." It was a checklist:

  1. Cap PHP memory per process (256 MB) — so a leaking plugin dies quietly instead of taking the whole server down.
  2. Limit FPM children per pool — fewer concurrent processes, predictable footprint.
  3. Tune OPcache deliberately — 384 MB is a ceiling, not a starting point, for a 2 GB server.
  4. Kill the double PHP-FPM — run one version, not two.

It caught what I would have missed. During the WordPress update that triggered all this, the agent flagged that a "WordPress Beta Tester" plugin was enabled — which is why the update went to a release candidate instead of a stable version. I'd have blamed the update. The agent found the root cause.

And it remembered. Two days later, when a Roundcube update wiped my PHP 8.3 override and webmail died, the agent didn't re-diagnose from scratch. It had a skill saved for exactly this: check the error log, confirm array_first(), re-apply the Apache override. Fixed in minutes instead of an hour of Googling.

The uncomfortable conclusion

WordPress isn't broken. It just grew — and grew in the direction of "more code, more features, more everything." That's fine when you can throw RAM at it. It's a rude awakening on a 2 GB box that used to feel roomy.

The real lesson: OPcache size is not a preference, it's a budget. On a small server, you're not tuning for speed anymore. You're tuning for survival.

And the meta-lesson: the best debugging tool isn't a faster way to check logs. It's something that reads the logs, correlates them with the config, does the math, and tells you the plan — while you sleep. The AI didn't replace my judgment. It removed the hours of mechanical work between "something is wrong" and "here's what's wrong."

If your WordPress server suddenly feels slower, check your OPcache hit rate before you blame the database. If it's sitting at 30%, your problem isn't your queries. It's that your server is trying to recompile the entire internet on every request.