How much CPU and RAM does a server actually need?

The question of how much CPU and RAM a server needs usually shows up the moment you open a pricing page and see ten plans with prices that differ by three or four times. Most people resolve it by feel: some grab the biggest plan "just in case" and pay for capacity they never touch, others pick the cheapest one and spend a week two weeks later figuring out why the site keeps dying at night with nothing useful in its own logs. Both mistakes have the same root cause: the decision got made without looking at either the workload or what a running server actually does with its resources. There's a reasonably precise way to do this instead. Start with rough numbers based on what the server will run, then let a few commands on the live box tell you where the estimate was wrong.

Short version. Start from the workload: a static site is fine on 1 vCPU and 1 GB of RAM, WordPress with a shop and a few plugins wants 2 vCPU and 2-4 GB, a Node.js or Python app usually needs 1-2 vCPU and 1-2 GB, a small database wants 2 vCPU and 4 GB for its buffer cache, and a handful of Docker containers together start at 4 vCPU and 8 GB. Treat these as a starting point, not a final answer. Once the server has run for a few days, check it directly: free -h shows how much memory is used and how much is actually available, top/htop shows which process is using it, and vmstat 1 5 shows whether processes are queuing for CPU and whether swap is active. Swap usage that keeps climbing and processes that vanish without an error of their own (that's the OOM killer at work) both mean the box is genuinely short on memory. If you sized it wrong, on KVM that's a plan upgrade, not a rebuild from scratch.

Start by naming what actually runs on the box

Before comparing numbers on a pricing page, figure out the workload type. It shapes the CPU-to-RAM ratio far more than a vague number like "visitors per day", and mixing the two up is the most common reason people size a server wrong.

• A static site or landing page - pre-built HTML, CSS and images that a web server just hands back on request. There's almost nothing for the CPU to compute, and memory needs are small.
• WordPress or another PHP CMS - every page request spins up a PHP process that runs code and talks to a database. More concurrent visitors means more of those processes running at once.
• A Node.js or Python application (an API, a bot, a background worker) - typically a single process with an event loop: it juggles many tasks quickly, but a genuinely heavy computation inside it blocks the whole process while it runs.
• A small database (MySQL, PostgreSQL) - cares less about the process itself and more about its buffer cache: the database keeps frequently read data in RAM so it doesn't have to hit disk for the same rows over and over.
• Several services running in Docker containers - each container is its own process or group of processes with its own footprint. Add them all up, plus a small overhead for the container engine itself.

How much CPU and RAM you need, by workload

Here's a starting table. Treat it as a baseline, not a guarantee: if your case sits on the edge of a range, take the lower number and watch the server rather than pre-paying for the upper one - upgrading later takes minutes, but you can't get a refund on capacity that sat idle.

If you're running a mixed setup, say WordPress plus a small Node.js service handling contact forms on the same box, add the RAM requirements together and take the higher of the two CPU requirements, not the average.

How to check what your server is actually using

Starting-point numbers are good enough for the first order. Once a server has run under real traffic for a few days, you get exact figures instead - you just need to know how to read them. Here are the commands in order, simplest first.

First, find out how many virtual cores the system actually sees:

nproc

It prints a single number, say 2. Don't read that as "how powerful" the server is - a VPS's vCPUs are usually fractions of the host's physical cores, but for planning parallelism (how many PHP-FPM workers to run, how many Node.js cluster processes to spawn) this is exactly the number that matters.

Next, memory. free shows how much RAM is in use, how much is free, and how much swap is reserved; the -h flag prints everything in megabytes and gigabytes instead of raw bytes.

free -h

A typical (illustrative) output looks like this:

total used free shared buff/cache available

Mem: 2.0Gi 780Mi 190Mi 18Mi 1.1Gi 1.0Gi

Swap: 2.0Gi 0B 2.0Gi

• used - memory actually held by running processes right now;
• buff/cache - the kernel's file cache; unlike used, the kernel hands this back to an application the instant it's needed, so a high number here isn't a problem by itself;
• available - an estimate of how much memory a new process could actually get without touching swap; this is the number to watch, not the raw free column;
• the Swap line with a climbing used value - a warning sign covered below.

To see which process is responsible for that usage, you need a live process monitor. top ships in almost every Ubuntu image out of the box; htop usually needs installing but is easier to read and lets you sort columns with the arrow keys.

sudo apt install htop -y

htop

You'll see a process list with CPU% and MEM% columns, which makes it immediately obvious who's using what: F6 switches the sort column, q quits.

A single snapshot doesn't show a trend - the load might just happen to be low at that exact second. vmstat, given an interval and a count, takes several readings in a row a set number of seconds apart, showing you the pattern instead of one random frame.

vmstat 1 5

• the first line is an average since boot, not the current state - look at the second line onward;
• the r column - how many processes are ready to run on the CPU right now; if it's regularly above the number from nproc, processes are literally queuing for cores;
• si/so - swap-in and swap-out rate in kilobytes per second; nonzero values repeating from line to line mean active swapping is happening right now;
• wa - the share of time the CPU spends waiting on disk I/O; a high number points at the disk, not at a CPU or RAM shortage.

Swap: a warning sign, not a fallback

Swap is disk space the Linux kernel uses to temporarily offload memory pages it isn't using much, when RAM runs short. It was designed as insurance against the occasional spike, not as a permanent source of memory: even on fast NVMe, swap is orders of magnitude slower than real RAM, and once a server starts swapping routinely, application latency climbs noticeably.

Check the current state of swap with:

swapon --show

Example output:

NAME TYPE SIZE USED PRIO

/swapfile file 2G 0B -2

A one-off bump in USED, say during a nightly backup job, is fine - that's swap doing exactly what it's for, and it releases the memory again afterward. The bad sign is USED climbing day after day and never coming back down: that means the server's working set genuinely doesn't fit in RAM anymore, and swap has quietly become a permanent crutch instead of an emergency buffer. The fix there isn't a bigger swap file, it's more RAM: an upgrade, not a bigger safety net.

The OOM killer: what happens when memory really runs out

When even swap isn't enough, the OOM killer (out-of-memory killer) steps in - a Linux kernel mechanism that forcibly terminates a process to keep the whole system from crashing. It picks its victim using an internal "badness" score (memory footprint plus a few other factors) - usually the hungriest process on the box, though not necessarily the one you'd have chosen yourself.

What makes this confusing is that it looks mysterious from the outside: a process just disappears, systemd restarts it at best, and there's nothing in the application's own logs explaining why, because it wasn't stopped from the inside, it was killed from the outside. If a service keeps restarting for no apparent reason, the first thing to check isn't its code, it's the kernel's own logs:

sudo journalctl -k | grep -i "killed process"

A line like Out of memory: Killed process 1234 (node) total-vm:... anon-rss:... in the output confirms the cause is server-wide memory pressure, not a bug in that particular process. Again, the right fix is more RAM, not restarting the service by hand and hoping it doesn't happen again.

journalctl -k | grep -i killed

If you're not sure, start small

You don't have to guess the exact number on the first try. On KVM virtualization, which is what WeaselCloud runs, upgrading a plan usually comes down to changing the configuration in the dashboard and rebooting once - no reinstall, no manual data migration; the full process is covered in the plan-change guide. That's different from OpenVZ and other container-based formats, where memory and swap can behave differently and sometimes are "elastic" rather than fixed - if you're not sure which virtualization your server runs, that's covered in KVM vs OpenVZ.

The practical takeaway: don't pad your first order for hypothetical future growth. Take the lower end of the table above, watch free -h and vmstat during the first week, and upgrade when available settles consistently below 10-15% or swap keeps climbing without recovering, not after the server has already restarted itself via the OOM killer a couple of times.

FAQ

How much RAM does a WordPress site need?

For a small site with a modest plugin set and up to a couple thousand visits a day, 2-4 GB of RAM and 2 vCPU is usually enough. Each concurrent visitor spins up a PHP-FPM process weighing roughly 30-50 MB, so with meaningful traffic or heavy plugins (page builders, cache plugins with large rule sets) it's worth checking real usage with free -h after a week of running rather than relying on the minimum figure alone.

How many CPU cores does a small VPS need?

A single vCPU is enough for a static site or a simple API - the bottleneck there is almost always memory or network, not the processor. A second core becomes necessary once several processes on the box can genuinely run in parallel: PHP-FPM with multiple workers, a database sitting next to the application, or a handful of Docker containers.

What does swap mean in free -h output?

The Swap line in free -h shows the size and current usage of the swap area, disk space the kernel uses to offload memory pages it isn't actively using when RAM runs short. A small, occasional bump in usage is normal, but swap usage that keeps climbing and never drops back down means the server is consistently short on real memory.

What is the OOM killer and why does it kill processes?

The OOM killer is a Linux kernel mechanism that forcibly stops a process when memory and swap are both exhausted, to prevent the entire system from crashing. It picks its target using an internal score, usually the process using the most memory, so finding a kernel log entry about an important service getting killed is a strong sign the server needs more RAM, not that the service itself has a bug.

How much RAM do a few Docker containers need?

For 3-5 small services (a lightweight API, a database, a cache, a reverse proxy) a reasonable starting point is 4 vCPU and 8 GB of RAM, but the exact figure comes from adding up each container's own footprint plus a small overhead for the container engine. The easiest way to check is docker stats against your running containers, which shows live memory and CPU usage per container.

Can you start with a small VPS plan and upgrade later?

Yes, and it's a reasonable strategy - you don't need to nail the exact number on the first attempt. On KVM-based servers, upgrading a plan is done through the control panel and typically requires one reboot, with no reinstall and no manual data transfer; see the plan-change guide for the full walkthrough.

Takeaways

• The starting number depends on the workload: 1 vCPU and 1 GB for a static site, 2 vCPU and 2-4 GB for WordPress, 1-2 vCPU and 1-2 GB for a Node.js/Python app, 2 vCPU and 4 GB for a small database, 4 vCPU and 8 GB or more for several Docker containers.
• These are starting points for a first order, not a guarantee - on the edge of a range, take the lower figure and watch the server rather than prepaying for headroom you may never use.
• nproc shows how many vCPUs the system sees; use that number when tuning worker/process counts.
• In free -h, the available column is more reliable than the raw free figure - it's a real estimate of memory a new process could get without swapping.
• A high buff/cache value in free -h isn't a problem, it's the kernel's file cache, and it gets released instantly on demand.
• vmstat 1 5 shows the trend: an r column above your core count means a CPU shortage, repeated nonzero si/so means active swapping right now.
• A one-off swap spike is normal; swap that keeps climbing and never drops is a clear sign the server is short on RAM specifically.
• The OOM killer terminates processes without leaving an error in their own logs - if a service restarts for no obvious reason, check journalctl -k | grep -i killed before you go digging through the application's code.
• On KVM servers, upgrading a plan is a config change and a reboot, not a move to a new server, so there's no need to overprovision your first order.

What's next

The full walkthrough for sizing a server, including disk and network, lives in the pillar article how to choose a VPS. If you're not sure what virtualization sits under your plan and how that affects memory and swap behavior, see KVM vs OpenVZ. And if you're still choosing between server formats altogether, there's VPS, VDS, cloud and dedicated servers.