I have looked at dozens of crashing VPSs over the years. I cannot remember one where anybody had changed the settings the operating system shipped with.
That is odd, because every VPS seller publishes tuning guides: how much memory the database may use, how many PHP processes to allow, how many connections the web server accepts. The guides assume someone retunes the server after every plugin, memory-limit or traffic change. A VPS is usually bought by someone who expected to set it up once.
What the Defaults Assume
The Ubuntu defaults:
- PHP-FPM allows 5 PHP processes per pool.
- PHP gives each request a memory limit of 128 MB.
- MySQL keeps 128 MB of data in memory for its cache.
These numbers are the same on a 1 GB server and on a 16 GB server. Five processes means the sixth visitor waits for one of the first five to finish. On a busy day the site is slow on a server that is mostly idle, and a 128 MB database cache on a server with gigabytes free sends the database to the disk for data it could have kept in memory.
How the Usual Fix Causes the Crash
The usual fix is to raise the process limit. Each PHP process may use up to PHP’s memory limit. WordPress plugins often ask for 256 MB, so somebody raises that too. Forty processes at 256 MB can ask for 10 GB on a 4 GB server. Most of the time they do not all ask at once, which is why the setting looks fine for weeks. When they do, Linux runs out of memory and kills the process using the most of it. On a WordPress server that is often the database, so the site goes down with “Error establishing a database connection” while the PHP processes that caused it carry on.
The Limits Form a Chain
Memory per PHP process, times the number of processes, plus the database cache, plus the web server, plus the operating system, has to fit inside the box with room to spare.
On a 4 GB server, keeping about 1 GB for the operating system and web server and 1 GB for the database cache leaves about 2 GB for PHP. How many processes fit in 2 GB depends on what one process actually uses. Across the WordPress sites we host, the average PHP process measures anywhere from about 170 MB to about 470 MB. At 170 MB, 2 GB holds about twelve processes. At 470 MB it holds four, which is fewer than the default you started from, so the count has to be measured per site.
Why It Does Not Stay Tuned
Even a well-tuned server drifts, because the chain breaks every time something changes:
- A plugin asks for a higher memory limit, a developer raises it, and the process count that was safe yesterday no longer fits.
- A new plugin or a WooCommerce extension makes each process heavier.
- A second site is added to the same server.
- Traffic grows, and the process count that was enough last year now queues visitors.
A couple of hours of a specialist’s time buys a configuration that is right for about a month, and then it needs retuning.
How We Handle It
In our hosting the database, web server and CDN are separate services, so the database cache is sized on its own server and does not compete with PHP for memory.
On the web server, each site has one line of configuration that holds its PHP version, its process count and its memory limit. They are set together, against what that site’s processes actually measure. When a site’s memory limit changes, its process count is checked on the same line. On our newer servers each site also has its own memory ceiling, so a site that outgrows its settings hits its own limit instead of taking memory from its neighbours.
Three Questions for Your VPS
- Has anyone changed the PHP process limit and the database memory since the server was built? If not, it is running on settings written for no server in particular.
- Do you know how much memory one PHP process of your site uses? Without that number, any process limit is a guess.
- When the memory limit was last raised, was the process count changed with it? If the answer is “what process count”, the chain is already broken.
If you run a VPS and want to know whether its limits fit together, I am happy to look at its settings with you.
