Budget VPS plans almost never fail at the average load you tested on day one. They fail at the first real spike, in a predictable order: disk IOPS first, memory second, CPU credits third. Knowing that order lets you test for it before your users do. This guide describes a four-part stress test you can run on any cheap plan in about 30 minutes.
Why the order of failure matters
Marketing specs describe peak capacity, not sustained behavior. On a $3–$8 plan the host is sharing storage, memory bandwidth and CPU scheduling with other tenants. Under sustained load the first constraint to bite is almost always the one the pricing page never mentions: IOPS.
| Failure point | Trigger | Observable symptom | Typical tier affected |
|---|---|---|---|
| Disk IOPS cap | Concurrent DB writes | High iowait, slow TTFB | $3–$10 |
| Memory exhaustion | Traffic spike, cache growth | OOM killer, 502s | $3–$6 |
| CPU credit depletion | Sustained compute | Latency cliffs, throttling | Burstable plans |
| Network shaping | Bandwidth burst | Speed drop to 10 Mbps | Metered plans |
Test 1: Disk IOPS with fio
Run a mixed random read/write workload that resembles a database, not a sequential file copy. Sequential tests flatter cheap storage; random 4K is what your app actually does.
fio --name=randrw --ioengine=libaio --rw=randrw --bs=4k --size=512M --numjobs=4 --runtime=60 --time_based --group_reporting- Watch the reported IOPS and, importantly, the 99th-percentile latency.
- Re-run while a second process writes — this simulates the noisy-neighbor case that single-tenant tests miss.
Test 2: Memory pressure with a controlled allocator
Do not use a naive memory bomb that gets killed instantly. Allocate gradually and watch for the cliff where the kernel starts swapping:
- Use
stress-ng --vm 1 --vm-bytes 80% --vm-hang 0and monitor withvmstat 1. - The moment
si/sostay non-zero, you have found your real usable ceiling. - Compare that ceiling to the advertised RAM — the gap tells you how honest the plan is.
Test 3: CPU credit behavior
Burstable plans let you exceed baseline CPU for short periods. Sustained work drains the credit balance and your performance collapses to the floor. Measure it:
- Run
sysbench cpu --threads=2 --time=0 runfor 15 minutes. - Record events/second every 60 seconds.
- If throughput drops sharply after the first 5–10 minutes, the plan is credit-limited and unsuitable for steady workloads like compilation or video encoding.
Test 4: Network shaping
Transfer a large file to a fast remote host and watch the rate over several minutes. Many budget providers allow a burst, then shape the connection. Sustained shaping at 10–50 Mbps is common; a plan advertised at “1 Gbps port” rarely sustains that for long. Use iperf3 against a public server and log the rate per second, not just the average.
Interpreting the results
- If IOPS collapse under concurrent random I/O, keep databases small or move them off the box.
- If the memory ceiling is far below advertised, treat the plan as one tier smaller than its label.
- If CPU credits deplete, use the plan for bursty web traffic only.
- If the network is shaped hard, add a CDN or cache aggressively at the edge.
The point is not to prove cheap plans are bad — most are perfectly adequate for a personal site, a small API or a learning lab. The point is to know which constraint you will hit, so you can design around it instead of discovering it at 2 a.m. When a plan’s real ceiling is documented up front, choosing gets far easier; you can review value-focused plans with clearly stated resources on the budget VPS comparison page.
A repeatable checklist
Run all four tests on any candidate plan during its refund window. Keep the numbers in a spreadsheet next to price per usable GB, and the plan that looks cheapest on the pricing page frequently stops being the cheapest in practice. That gap between advertised and delivered is exactly what a good value provider closes — and what you should measure before committing. For plans that publish renewal rates and resource limits openly, start from the main comparison table.

