There is no single answer, because a static page and a busy online shop are different workloads. But most sites fall into a few patterns, and you can measure your own usage instead of guessing.
A small WordPress or PHP site runs comfortably on 1 to 2 GB of RAM and 1 to 2 vCPUs. A busy site with a shop, many plugins or heavy traffic usually wants 4 GB or more. Memory usually runs out before CPU does.
Starting points
| Site | RAM | vCPU | Notes |
|---|---|---|---|
| Static HTML site | 512 MB | 1 | The web server barely works |
| Small WordPress or PHP site | 1 to 2 GB | 1 to 2 | Add page caching and it will handle a lot |
| Several small sites on one server | 2 to 4 GB | 2 | Each PHP pool and database adds overhead |
| WooCommerce or membership site | 4 to 8 GB | 2 to 4 | Logged-in users bypass page caches |
| Large application or busy store | 8 GB and up | 4 and up | Consider separating the database |
These assume one server running the web server, PHP and the database together.
Where the memory goes
- The database. MySQL or MariaDB keeps frequently used data in memory. It is often the largest single user.
- PHP workers. Each PHP process that handles a request can use 50 to 150 MB with a heavy plugin set. Ten busy workers can easily use a gigabyte.
- The operating system and file cache. Linux uses spare memory to cache files. That is good, and it is why “used” memory looks high on healthy servers.
When memory runs out, the server starts swapping to disk and slows dramatically, or the kernel stops a process, often the database. Both show up as a slow or broken site.
Size PHP to the memory you have
PHP-FPM’s pm.max_children sets how many requests PHP can handle at once, and each one holds memory. Set it from your numbers, not a guess. First measure the average worker:
ps --no-headers -o rss -C php-fpm8.3 | awk '{sum+=$1; n++} END {printf "%d workers, %.0f MB average\n", n, sum/n/1024}'
On AlmaLinux, Rocky and RHEL, the process is called php-fpm. Then work out the budget:
- Take the server’s total memory.
- Subtract what the database uses (check its line in
top), plus about 300 MB for the operating system and web server. - Divide what is left by the average worker size.
A 2 GB server with a 500 MB database and 80 MB workers gives (2048 − 500 − 300) ÷ 80 ≈ 15. Set pm.max_children a little below that, so a heavy page does not push the server over the edge. Too many workers is worse than too few: the server runs out of memory and the kernel kills the database.
Give the database the right share
MariaDB and MySQL keep their working data in the InnoDB buffer pool. Its size is set by innodb_buffer_pool_size. On a server that only runs the database, half to three quarters of memory is normal. On a small server shared with PHP, keep it modest:
[mysqld]
innodb_buffer_pool_size = 256M
For a single WordPress site, a buffer pool a little larger than the database itself is plenty. Check the database size with:
sudo mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS MB FROM information_schema.tables GROUP BY table_schema;"
Add swap as a safety net
Swap is disk space the server can use when memory runs out. It is much slower than memory, so it is not a substitute for enough RAM, but it gives you time instead of a crashed database. Many cloud servers come with none. A 1 to 2 GB swap file is a sensible safety net on a small server:
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo "/swapfile none swap sw 0 0" | sudo tee -a /etc/fstab
Lower how eagerly the system swaps, so it only uses swap when memory is genuinely short:
echo "vm.swappiness=10" | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system
When CPU matters more
Memory is usually the first limit, but some work is CPU-bound: image resizing on upload, search on large sites, shops recalculating carts for many logged-in users, and sites without page caching under traffic. In top, a load average consistently above your vCPU count while memory is fine means you need more CPU, or less work per request.
Why caching changes everything
A cached page is served as a ready-made file without running PHP or touching the database. With page caching, a 2 GB server can serve many thousands of visitors a day. Without it, every visit runs the full application. See what caching is.
Measure your own site
On a Linux server, these show what is actually happening:
free -h
top
In free -h, look at the available column, not “free”. In top, press M to sort by memory and P to sort by CPU. Watch during your busiest hour. If available memory regularly drops below about 10 percent, or swap use keeps climbing, it is time for more RAM or better caching.
Related
- Shared, VPS, dedicated or cloud hosting.
- 503 Service Unavailable, what visitors see when PHP runs out of workers.
- Error establishing a database connection, often a database killed for lack of memory.
Something out of date? Software changes. If a step no longer works, tell us and we will check it and update the page.

