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.<\/p>\n\n\n\n
Before choosing anything, measure the plan you already have. Run these three commands during peak traffic and record the results:<\/p>\n\n\n\n
# 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}'
<\/code><\/pre>\n\n\n\nIn vmstat<\/code>, look at the r<\/code> column (run queue). If r<\/code> consistently exceeds your vCPU count, you are CPU-bound. In free -m<\/code>, if available memory is under 15% and pgscan<\/code> is climbing, you are memory-bound. In iostat -x<\/code>, if await<\/code> 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.<\/p>\n\n\n\nWorkload-to-Resource Mapping<\/h2>\n\n\n\nWorkload<\/th> Primary constraint<\/th> Secondary<\/th> Typical minimum<\/th><\/tr><\/thead> Static site + Nginx<\/td> Network \/ memory<\/td> \u2014<\/td> 1 vCPU \/ 1 GB<\/td><\/tr> WordPress + MySQL + PHP-FPM<\/td> RAM<\/td> CPU bursts<\/td> 2 vCPU \/ 2 GB<\/td><\/tr> Node.js \/ Python API<\/td> CPU (single-thread)<\/td> RAM<\/td> 2 vCPU \/ 2 GB<\/td><\/tr> PostgreSQL \/ MySQL OLTP<\/td> Disk IOPS + RAM<\/td> CPU<\/td> 2 vCPU \/ 4 GB<\/td><\/tr> Redis in-memory store<\/td> RAM<\/td> Network<\/td> 2 vCPU \/ 4 GB<\/td><\/tr> CI runner \/ build agent<\/td> CPU cores<\/td> Disk write<\/td> 4 vCPU \/ 8 GB<\/td><\/tr> Video transcode<\/td> CPU cores<\/td> Disk throughput<\/td> 8 vCPU \/ 8 GB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\nThe 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.<\/p>\n\n\n\n
Estimating RAM for the LAMP\/LEMP Stack<\/h2>\n\n\n\n
On a 2 GB VPS running Nginx, PHP-FPM, and MySQL, a realistic steady-state budget looks like this:<\/p>\n\n\n\n
- Kernel + base OS:<\/strong> 150\u2013250 MB<\/li>
- Nginx workers:<\/strong> 20\u201340 MB total for a low-traffic site<\/li>
- PHP-FPM:<\/strong> 30\u201360 MB per active worker \u2014 10 workers can consume 600 MB<\/li>
- MySQL:<\/strong> InnoDB buffer pool plus per-connection overhead \u2014 budget 512 MB on a 2 GB box<\/li>
- Redis (if used):<\/strong> 64\u2013128 MB with an eviction policy and
maxmemory<\/code> set<\/li><\/ul>\n\n\n\nThe PHP-FPM pool is the most common hidden consumer. Setting pm.max_children<\/code> 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 \u2014 burst handling belongs at the caching layer, not in worker count.<\/p>\n\n\n\nDisk IOPS: The Spec Sheet’s Blind Spot<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Measure before you migrate, and again after. A provider whose disk subsystem quietly throttles writes will show up as rising await<\/code> and %util<\/code> as your dataset grows \u2014 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.<\/p>\n\n\n\nMatching vCPU Count to Parallelism<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
- Steal time<\/strong> \u2014 CPU time your VM wanted but could not get because the host was busy. Read it in
top<\/code> or mpstat<\/code>. Sustained steal above 5% means you are paying for cores you do not receive.<\/li>- Single-thread performance<\/strong> \u2014 many runtimes (Node.js event loop, Python GIL, PHP request handling) are effectively single-threaded, so one fast core beats four contended ones.<\/li><\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
A Repeatable Sizing Procedure<\/h2>\n\n\n\n