VPS Plan Sizing by Workload: Mapping CPU Cores, RAM, and Disk IOPS to Real Applications

Most VPS plan decisions are made by picking a number that feels safe and then discovering six months later that one resource is saturated while the other two sit idle. The failure mode is almost always the same: buyers compare plans by total specs instead of by the resource that actually limits their workload. This guide maps common applications to the specific resource that constrains them, with concrete numbers you can check against your own server.

Start by Finding Your Limiting Resource

Before choosing anything, measure the plan you already have. Run these three commands during peak traffic and record the results:

# CPU saturation (not just load average)
vmstat 1 10

# Memory pressure incl. swap activity
free -m && cat /proc/vmstat | grep -E 'pgscan|pgsteal'

# Disk latency percentiles
iostat -x 1 10 | awk '{print $1, $2, $14, $15, $16}'

In vmstat, look at the r column (run queue). If r consistently exceeds your vCPU count, you are CPU-bound. In free -m, if available memory is under 15% and pgscan is climbing, you are memory-bound. In iostat -x, if await for your data device is above 10 ms on SSD or above 1 ms on NVMe, you are I/O-bound. The resource that saturates first is the one your next plan must increase.

Workload-to-Resource Mapping

Workload	Primary constraint	Secondary	Typical minimum
Static site + Nginx	Network / memory	—	1 vCPU / 1 GB
WordPress + MySQL + PHP-FPM	RAM	CPU bursts	2 vCPU / 2 GB
Node.js / Python API	CPU (single-thread)	RAM	2 vCPU / 2 GB
PostgreSQL / MySQL OLTP	Disk IOPS + RAM	CPU	2 vCPU / 4 GB
Redis in-memory store	RAM	Network	2 vCPU / 4 GB
CI runner / build agent	CPU cores	Disk write	4 vCPU / 8 GB
Video transcode	CPU cores	Disk throughput	8 vCPU / 8 GB

The table is a starting point, not a rule. A WordPress site with Redis object caching and a full-page cache needs far less RAM than the same site with neither, because caching moves the constraint from MySQL to the network path. Once you understand which layer is doing the work, plan sizing becomes arithmetic.

Estimating RAM for the LAMP/LEMP Stack

On a 2 GB VPS running Nginx, PHP-FPM, and MySQL, a realistic steady-state budget looks like this:

Kernel + base OS: 150–250 MB
Nginx workers: 20–40 MB total for a low-traffic site
PHP-FPM: 30–60 MB per active worker — 10 workers can consume 600 MB
MySQL: InnoDB buffer pool plus per-connection overhead — budget 512 MB on a 2 GB box
Redis (if used): 64–128 MB with an eviction policy and maxmemory set

The PHP-FPM pool is the most common hidden consumer. Setting pm.max_children to 25 “just in case” on a 2 GB server guarantees swap under load. Size the pool to match your actual concurrent request count, not your traffic peaks — burst handling belongs at the caching layer, not in worker count.

Disk IOPS: The Spec Sheet’s Blind Spot

Providers advertise “SSD storage” without publishing IOPS guarantees, because on a VPS you share the backing storage with other tenants. What you actually receive is a fraction of the host’s aggregate IOPS, throttled per-tenant. A database workload that needs 3,000 random read IOPS will behave very differently on two providers that both claim local NVMe.

Measure before you migrate, and again after. A provider whose disk subsystem quietly throttles writes will show up as rising await and %util as your dataset grows — long before the CPU graph shows anything. If your workload is IOPS-sensitive, verify the storage behaviour in the first week and treat it as a deal-breaker if it cannot sustain your baseline.

Matching vCPU Count to Parallelism

A vCPU is a time slice on a physical core, and the number you are sold is a share, not a guarantee. Two things determine how much throughput that share delivers:

Steal time — CPU time your VM wanted but could not get because the host was busy. Read it in top or mpstat. Sustained steal above 5% means you are paying for cores you do not receive.
Single-thread performance — many runtimes (Node.js event loop, Python GIL, PHP request handling) are effectively single-threaded, so one fast core beats four contended ones.

For CPU-bound work, confirm the usable core count with a short parallel benchmark rather than trusting the spec sheet. If a 4-vCPU plan’s benchmark scores like a 2-vCPU plan, the extra cores are not being delivered.

A Repeatable Sizing Procedure

Instrument first. One week of vmstat, iostat, and memory data tells you the limiting resource more accurately than any calculator.
Identify the ceiling. Note the utilisation at which response time degrades — that is your effective capacity, not the spec limit.
Size the next plan for 2× headroom on the limiting resource only. Oversizing the other two just raises cost.
Re-measure after migration. Provider behaviour differs more than the specs suggest.
Revisit quarterly. Workloads drift; the resource that was constrained at launch may not be the one constrained now.

Putting It Together

Plan sizing is a measurement problem, not a comparison-shopping problem. Find the resource that saturates first, buy headroom on that resource, and verify the new server actually delivers it. If you are still choosing a starting point, the VPS plans at virtualserversvps.com give you the vCPU, RAM, and storage figures you need to apply this mapping directly — then confirm them with the commands above during your first week.