RAM is usually the first resource a server runs out of. CPU shortages make things slow; memory shortages make things crash — the kernel’s out-of-memory killer terminates processes, often your database. Here’s how to size RAM for common workloads, and how to check whether you got it right.
Quick guide
| Workload | Minimum | Comfortable |
|---|---|---|
| Static sites, small VPN, bots, monitoring | 512 MB–1 GB | 1–2 GB |
| One WordPress blog (Nginx + PHP-FPM + MariaDB) | 1 GB | 2 GB |
| Several WordPress sites, or one busy site | 2 GB | 4 GB |
| WooCommerce store | 2 GB | 4–8 GB |
| Node.js / Python app + PostgreSQL | 1–2 GB | 4 GB |
| Docker host with 5–10 self-hosted apps | 2–4 GB | 4–8 GB |
| Nextcloud for a family / small team | 2 GB | 4 GB |
| Dedicated database server | 4 GB | 8–16 GB+ (working set in RAM) |
| Minecraft Java server (vanilla, few players) | 2–3 GB | 4–8 GB |
| Windows Server | 2 GB | 4 GB+ |
| Local LLM (small quantized models, CPU) | 8 GB | 16 GB+ |
These are starting points; actual usage depends on traffic, plugins and configuration.
Where the memory goes
The operating system
A minimal Linux server uses 150–300 MB. Windows Server needs about 1.5–2 GB just for itself, which is why Windows plans need more RAM for the same workload.
Web stack (PHP)
Each PHP-FPM worker typically uses 40–120 MB, and you need enough workers for concurrent requests. Five workers × 80 MB = 400 MB. A busy site with 20 workers needs 1.5 GB+ for PHP alone. Page caching drastically cuts how many workers you need, because cached pages never reach PHP.
Databases
MySQL/MariaDB and PostgreSQL perform best when frequently used data fits in memory (innodb_buffer_pool_size, shared_buffers). A small WordPress database is under 100 MB; a store with years of orders can be several GB. Give the database enough to hold its working set.
Node.js, Python, Java
A Node.js process starts around 50–100 MB and grows with your app; frameworks like Next.js use more during builds than at runtime. Python apps with several Gunicorn workers multiply their footprint. Java applications reserve heap up front — a Spring Boot app often wants 512 MB–1 GB.
Docker
Containers themselves add little overhead, but each app brings its own runtime and often its own database. Ten small apps × 100–300 MB adds up quickly.
Caches
Redis, the OS page cache, OPcache — memory used for caching is memory well spent. Linux uses “free” RAM as disk cache automatically.
Measure, don’t guess
On an existing server:
free -h total used free shared buff/cache available
Mem: 3.8Gi 1.6Gi 250Mi 60Mi 2.0Gi 1.9Gi
Swap: 2.0Gi 12Mi 2.0GiLook at available, not “free”. Linux fills spare memory with disk cache (buff/cache) and releases it when applications need it. Low “free” is normal; low “available” is a problem.
Find the biggest consumers:
ps aux --sort=-%mem | head -15Watch for trouble signs:
sudo journalctl -k | grep -i "out of memory" # OOM killer events
vmstat 5 # si/so columns > 0 constantly = swappingSee also free command and CPU and RAM monitoring.
Signs you need more RAM
- The OOM killer appears in kernel logs, or MySQL restarts unexpectedly.
- Constant swap activity (
si/soinvmstat) and sluggish response. - “Available” memory stays below ~10–15% at normal load.
- You can’t run enough PHP or app workers to handle traffic without errors.
Ways to stretch RAM
Before upgrading:
- Add swap as a safety net (not as a substitute for RAM) — see swap file vs partition, or zram for compressed in-memory swap.
- Tune worker counts — PHP-FPM
pm.max_children, Gunicorn workers, PM2 instances — to fit your RAM. - Right-size the database buffer pool rather than leaving defaults.
- Cache pages so fewer requests hit PHP and the database.
- Remove unused services (
systemctl list-units --type=service --state=running). - Use Alpine or slim Docker images and limit container memory.
RAM vs CPU: which to upgrade?
If the server is slow but memory is fine, check CPU: high load average and %us/%sy in top point to CPU limits. If memory is tight but CPU is idle, more RAM is the fix. See how many CPU cores you need.
Start small, upgrade when the data says so
It’s easier and cheaper to start with a modest plan and upgrade based on real measurements than to guess big. Our VPS plans run from 2 GB to 40 GB of RAM in USA, Hong Kong and Japan, and moving to a larger plan is a quick support ticket when you need it.