Disk I/O is the resource that VPS providers throttle most aggressively, and it is also the hardest to verify from a spec sheet. CPU cores and RAM amounts are printed on every pricing page, but sustained IOPS, burst credits, and bandwidth ceilings usually live in the fine print — if they are documented at all. If you run a database, build pipelines, or take nightly backups on your VPS, a hidden I/O cap can turn a fast server into a sluggish one. This article explains how providers enforce I/O limits, how burst and sustained performance differ, and exactly how to test what your plan actually delivers.
How Providers Enforce I/O Limits
Providers enforce I/O limits at the hypervisor or storage layer rather than inside your VM, so tools like iostat show the result while the policy itself stays invisible. In practice, almost every provider uses one or more of these mechanisms on its shared storage:
- IOPS caps: a hard ceiling on read/write operations per second, applied per VM via cgroups, disk quotas, or storage QoS.
- Bandwidth ceilings: a separate MB/s throughput limit that binds long sequential transfers even when the IOPS cap is never reached.
- Burst credits: a short window of full-speed I/O that refills over time — great for benchmarks, misleading for steady workloads.
- Post-burst throttling: after the credit bucket empties, throughput drops to a small fraction (sometimes 5–20%) of the burst rate.
Burst vs. Sustained Limits: Reading the Fine Print
The burst model causes the most confusion. A fresh instance benchmarks beautifully for the first minute, then falls off a cliff when the credit bucket empties. That is not a fault in your configuration — it is the designed behavior of the storage tier you are paying for. The number that matters for production work is the sustained rate: the throughput you can rely on indefinitely, not the peak you can hit for sixty seconds.
Two questions separate honest plans from marketing ones. First: how long does the burst window last, and how long does refill take? A provider that refills credits in seconds is far more forgiving than one that takes hours. Second: what happens after throttling kicks in — does performance drop to 10% of the burst rate or 80%? Both answers should be documented in the provider’s knowledge base; if they are not, ask support and keep the reply.
How to Test Your VPS I/O
The standard tool is fio. Install it on Debian or Ubuntu with sudo apt update && sudo apt install -y fio, then start with a 4K random-read test, which reflects the access pattern of databases and package managers:
fio --name=randread --rw=randread --bs=4k --size=1G --runtime=60 --iodepth=32 --numjobs=4 --group_reportingThen test random writes, always with direct I/O so results reflect the device rather than the page cache:
fio --name=randwrite --rw=randwrite --bs=4k --size=1G --runtime=60 --iodepth=16 --direct=1 --group_reportingWithout --direct=1, writes land in RAM first and the numbers look flattering but meaningless. Latency matters as much as throughput: run ioping -c 20 . to measure round-trip I/O latency. A healthy SSD tier returns sub-millisecond results, while throttled budget tiers often show 5–50 ms under load. Finally, run a long burst test — fio --name=burst --rw=randread --bs=4k --size=4G --runtime=300 --iodepth=32 --group_reporting — and watch the IOPS curve over five minutes. The point where it drops is your real sustained limit.
In the fio summary, read the read: IOPS= and bw= lines, plus the clat (completion latency) percentiles. A provider that caps IOPS shows a flat, perfectly linear IOPS line once the cap is reached; an uncapped shared array shows noisier numbers because you are competing with neighbors.
What the Numbers Mean
| Storage tier | Sustained 4K random read | Latency under load |
|---|---|---|
| Budget shared SSD | 500–2,000 IOPS | 5–50 ms |
| Mid-range SATA SSD | 5,000–20,000 IOPS | 0.5–2 ms |
| NVMe (dedicated or near-dedicated) | 20,000–100,000+ IOPS | < 0.5 ms |
Watching I/O Over Time
Single benchmarks are snapshots; throttling often appears only under sustained load or during the provider’s peak hours. Install sysstat and keep iostat -x 5 running while your workload runs. Watch %util (how busy the device is), await (average response time), and w_await (write latency). Consistently high await with low %util points to remote or contended storage rather than a saturated local disk. Pair this with vmstat 1 to correlate I/O stalls with CPU steal — sometimes the “disk problem” is actually the hypervisor pausing your vCPUs.
What to Check Before You Buy
- Look for documented IOPS and bandwidth caps in the provider’s docs, not just “SSD” or “NVMe” labels.
- Ask support for the sustained (non-burst) IOPS number on the plan you are considering.
- Check how long the burst window lasts and how long refill takes.
- Treat “unlimited I/O” claims with suspicion — someone is always sharing the array.
- Run your fio tests during the provider’s peak hours before committing.
When comparing plans, the VPS feature comparison at virtualserversvps.com highlights which vendors publish real sustained IOPS numbers, and the provider list on the same page links to documentation where you can check burst policies before committing.
If sustained I/O matters for your workload, pick a plan that publishes its limits instead of one that hides them. Compare VPS plans with transparent storage specs and find a tier that publishes its real I/O limits.
Leave a Reply
You must be logged in to post a comment.