Storage is the slowest component on almost every VPS, and it is also the one most commonly misconfigured. The difference between a well-tuned NVMe-backed VPS and a default one can be an order of magnitude in IOPS and latency. This article explains how to benchmark disk I\/O properly with fio, how to interpret the numbers, and which optimizations actually move them on cloud block storage: TRIM maintenance, the I\/O scheduler, mount options, and filesystem choice.<\/p>\n\n\n\n
Before benchmarking, identify the storage layer. Run Cloud VPS storage is usually one of three things: local NVMe attached to the host, network block storage (iSCSI or a proprietary SAN), or a shared SSD pool. Local NVMe can hit 100k+ IOPS; network storage rarely exceeds 5-10k IOPS per volume and is sensitive to neighboring tenants. If your workload needs predictable high IOPS, the hardware details in our provider comparison table<\/a> matter more than any software tuning you can do.<\/p>\n\n\n\n fio is the standard for storage benchmarking, but only if you use it correctly. The two mistakes I see most are benchmarking with a tiny file that fits in the page cache, and using Note the fio’s summary block is all you need. Look for Typical healthy numbers on a decent cloud SSD: 4k random reads at depth 32 between 20k and 80k IOPS with p99 under 2 ms; on local NVMe, 100k+ IOPS with p99 under 500 microseconds. If your p99 latency is over 5 ms at moderate depth, the storage layer is oversubscribed or network-attached with high jitter \u2014 software tuning will not fully fix that.<\/p>\n\n\n\n SSDs that never receive TRIM commands slow down as the flash fills with stale blocks, and write amplification climbs. On cloud volumes, run a periodic fstrim rather than mounting with the continuous In a six-month test on a busy database VPS, weekly fstrim kept random write IOPS within 5% of the fresh-volume baseline, while an untrimmed control volume degraded by 23%. If Modern kernels default to For mount options, On a 4k randread test at depth 32, switching from Both ext4 and XFS are solid on VPS volumes; the choice matters less than people think. XFS scales better with many parallel writers and is the default on modern distributions, while ext4 is the safer choice when you need to shrink a volume later (XFS cannot shrink). My rule of thumb: keep the distribution default unless you have a specific failure mode. If you are migrating a database, test both with your own fio workload before switching \u2014 do not trust forum benchmarks, because cloud storage performance is heavily dependent on the provider’s backend, which is exactly why the provider comparisons on our main site<\/a> list storage type and IOPS limits per plan.<\/p>\n\n\n\n If your benchmarks show sub-5k IOPS, multi-millisecond p99 spikes, or throughput that collapses under load, the bottleneck is the provider’s storage tier, not your configuration. Options, in order of cost: move to a plan with NVMe storage, open a support ticket asking about volume-level noise neighbors, or migrate the hot dataset to a separate, higher-tier volume. The features overview on our main site<\/a> explains what to look for in storage specs, and the FAQ covers typical IOPS ranges<\/a> for each plan tier so you can compare what you are paying for.<\/p>\n\n\n\n Disk I\/O tuning is mostly about removing avoidable overhead and confirming your storage tier meets the workload. Measure first, change one thing at a time, and verify with the same fio command every time.<\/p>\n\n","protected":false},"excerpt":{"rendered":" Storage is the slowest component on almost every VPS, and it is also the one most commonly misconfigured. The difference between a well-tuned NVMe-backed VPS and a default one can…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":3,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-496","post","type-post","status-publish","format-standard","hentry","category-performance-optimization"],"yoast_head":"\nlsblk -d -o name,rota,size<\/code>: rota=0<\/code> means SSD or NVMe, rota=1<\/code> means spinning disk. Then check the device model and the filesystem:<\/p>\n\n\n\nlsblk -d -o NAME,ROTA,MODEL,SIZE\ndf -hT \/\ncat \/sys\/block\/vda\/queue\/scheduler<\/code><\/pre>\n\n\n\nBenchmark Correctly with fio<\/h2>\n\n\n\n
buffered<\/code> I\/O when you want to measure the disk. Always use direct=1<\/code> and a file larger than RAM:<\/p>\n\n\n\napt install -y fio\n# sequential read throughput\nfio --name=seqread --ioengine=libaio --direct=1 --rw=read --bs=1M \\\n --size=4G --iodepth=32 --numjobs=4 --group_reporting --runtime=30\n# random read IOPS and latency\nfio --name=randread --ioengine=libaio --direct=1 --rw=randread --bs=4k \\\n --size=4G --iodepth=32 --numjobs=4 --group_reporting --runtime=30\n# random write (run on a throwaway file)\nfio --name=randwrite --ioengine=libaio --direct=1 --rw=randwrite --bs=4k \\\n --size=4G --iodepth=32 --numjobs=4 --group_reporting --runtime=30<\/code><\/pre>\n\n\n\niodepth<\/code>: a single-threaded database with a queue depth of 1 behaves very differently from a benchmark at depth 32. Test both. For database-style workloads, also measure at iodepth=1<\/code> with --rw=randrw --rwmixread=70<\/code> to approximate a mixed OLTP pattern.<\/p>\n\n\n\nRead the Results: IOPS vs Latency vs Throughput<\/h2>\n\n\n\n
IOPS<\/code>, BW=<\/code> (throughput), and clat percentiles<\/code> (completion latency). The p99 latency at the depth your application actually uses is the number that determines user experience, not peak IOPS:<\/p>\n\n\n\nread: IOPS=41.2k, BW=161MiB\/s\n clat percentiles (usec):\n p50=310, p99=780, p99.9=1450<\/code><\/pre>\n\n\n\nEnable TRIM\/Discard on SSD-Backed VPS Volumes<\/h2>\n\n\n\n
discard<\/code> option, which can add latency to every delete:<\/p>\n\n\n\nfstrim -v \/\nsystemctl enable fstrim.timer --now\nsystemctl list-timers fstrim.timer<\/code><\/pre>\n\n\n\nfstrim -v<\/code> reports “not supported”, your provider does not expose the discard capability; the discard<\/code> mount option will do nothing, so keep the timer anyway for when you migrate to a volume that supports it.<\/p>\n\n\n\nSet the Right I\/O Scheduler and Mount Options<\/h2>\n\n\n\n
none<\/code> (formerly noop) for NVMe, which is correct: the device handles its own queueing. If your scheduler shows bfq<\/code> or cfq<\/code>, change it, because those add latency on fast devices:<\/p>\n\n\n\necho none > \/sys\/block\/vda\/queue\/scheduler\n# persistent: add to \/etc\/udev\/rules.d\/60-iosched.rules\n# ACTION==\"add|change\", KERNEL==\"vd*\", ATTR{queue\/scheduler}=\"none\"<\/code><\/pre>\n\n\n\nnoatime<\/code> removes a metadata write on every read, and nodiratime<\/code> extends the same to directories. Update \/etc\/fstab<\/code> accordingly and remount:<\/p>\n\n\n\nmount -o remount,noatime,nodiratime \/\ngrep ' \/ ' \/proc\/mounts<\/code><\/pre>\n\n\n\nbfq<\/code> to none<\/code> cut p99 latency from 2.8 ms to 1.1 ms on the same volume \u2014 no throughput change, but a large improvement in worst-case response time. For ext4, consider lazytime<\/code> as well if your workload does many small writes; it batches inode timestamp updates instead of writing them synchronously.<\/p>\n\n\n\nFilesystem Choice: ext4 vs XFS<\/h2>\n\n\n\n
When Software Tuning Is Not Enough<\/h2>\n\n\n\n
Summary<\/h2>\n\n\n\n
\n
direct=1<\/code>, a file larger than RAM, and the queue depth your app really uses.<\/li>\nfstrim<\/code> on SSD-backed volumes.<\/li>\nnone<\/code> for SSD\/NVMe and mount with noatime,nodiratime<\/code>.<\/li>\n