VPS Disk I/O Optimization: How to Benchmark and Improve Storage Performance

Disk I/O is often the silent bottleneck on a VPS. Your CPU may be idle at 10% and your RAM half-used, but if the storage subsystem can’t keep up with read and write requests, your applications will stall. Database queries run slow, page loads time out, and file operations feel sluggish. This guide covers how to benchmark your VPS’s disk performance, interpret the results, and apply practical optimizations to maximize storage throughput.

Understanding Disk I/O Metrics

Three metrics matter for disk performance:

• IOPS (Input/Output Operations Per Second) — How many individual read or write operations the disk can handle per second. Critical for databases and applications with many small, random I/O operations.
• Throughput (MB/s) — How much data can be read or written per second. Important for large file transfers, media streaming, and batch processing.
• Latency (ms) — How long each individual I/O operation takes. High latency kills interactive application performance even if IOPS and throughput look fine.

The type of storage your provider uses directly impacts these numbers. NVMe SSDs deliver 500,000+ IOPS and sub-100µs latency. SATA SSDs deliver 50,000-100,000 IOPS with 100-500µs latency. Traditional HDDs (rare in modern VPS) deliver only 100-200 IOPS with 5-15ms latency. Always check what storage technology your provider provisions before signing up — you can compare VPS hosting plans to see which providers offer NVMe at each price tier.

Tool 1: fio — The Gold Standard for Benchmarking

fio (Flexible I/O Tester) is the most comprehensive disk benchmarking tool available. It can simulate virtually any I/O workload pattern:

sudo apt install fio

Run separate benchmarks for random reads, random writes, sequential reads, and sequential writes. Here’s a typical random 4K read test — the most relevant metric for database workloads:

fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 
    --name=test --bs=4k --iodepth=64 --size=4G 
    --readwrite=randread --numjobs=4

Key parameters explained:

• --bs=4k — Block size of 4KB (standard database page size). Use 64K-1M for sequential throughput tests.
• --iodepth=64 — 64 concurrent I/O operations. Higher values stress the disk’s queue depth handling.
• --size=4G — Test file size. Use at least 2-4x your VPS’s RAM to bypass caching effects.
• --direct=1 — Bypass the OS page cache so you’re testing raw disk performance.

Run the same test with --readwrite=randwrite for write performance, --readwrite=read for sequential reads, and --readwrite=write for sequential writes. A healthy NVMe VPS should deliver:

Workload	NVMe VPS	SATA SSD VPS	HDD VPS (rare)
4K Random Read (IOPS)	80,000 – 300,000+	10,000 – 40,000	100 – 200
4K Random Write (IOPS)	40,000 – 150,000+	5,000 – 20,000	50 – 150
Sequential Read (MB/s)	1,000 – 6,000+	200 – 500	50 – 150
Sequential Write (MB/s)	500 – 3,000+	150 – 400	30 – 100

Tool 2: iostat — Real-Time I/O Monitoring

While fio measures maximum capability, iostat shows what your disk is actually doing under real workloads:

iostat -x 5

The -x flag shows extended statistics, and 5 refreshes every 5 seconds. Key columns to watch:

• r/s, w/s — Read and write operations per second. Compare against your fio benchmark to see how close you are to your disk's limit.
• await — Average I/O latency in milliseconds. Below 2ms is excellent for NVMe. Above 10ms indicates contention or throttling.
• svctm — Service time. If this is consistently above await, the storage subsystem is saturated.
• %util — Percentage of time the disk was busy. If this hits 100%, your disk is the bottleneck.

Optimization 1: Choose the Right Filesystem and Mount Options

The filesystem and mount options have a significant impact on I/O performance:

# Check current filesystem
df -Th

# For ext4 — optimize with noatime and increased commit interval
sudo mount -o remount,noatime,commit=60,nodiratime /

• noatime — Disables updating the access time on every file read. This alone can double read IOPS for file-heavy workloads.
• nodiratime — Same as noatime but for directory inodes.
• commit=60 — Flush data every 60 seconds instead of the default 5. Reduces write frequency but increases data loss risk on crash. Use only for non-critical data.

If you're provisioning a new VPS, consider using XFS instead of ext4. XFS generally handles large files and parallel I/O better, especially with the largeio and nobarrier mount options (provided your storage backend has battery-backed cache).

Optimization 2: Tune the I/O Scheduler

The I/O scheduler decides the order in which read/write requests are dispatched to the disk. For NVMe SSDs, the best choice is none (no scheduling — let the hardware handle it):

# Check current scheduler
cat /sys/block/vda/queue/scheduler

# Set to none (replace vda with your device name)
echo none > /sys/block/vda/queue/scheduler

# Make permanent via udev rule
echo 'ACTION=="add|change", KERNEL=="vda", ATTR{queue/scheduler}="none"' > /etc/udev/rules.d/60-iosched.rules

For SATA SSDs, mq-deadline is a good option. For HDDs, bfq (Budget Fair Queuing) prevents a single process from starving others.

Optimization 3: Increase Kernel I/O Parameters

Several sysctl parameters directly affect disk I/O performance. Add these to /etc/sysctl.conf:

# Increase dirty page cache limits (write performance)
vm.dirty_ratio = 30
vm.dirty_background_ratio = 10

# Increase the maximum number of pending I/O requests
vm.vfs_cache_pressure = 50

# Reduce swap tendency (avoid swapping when memory is available)
vm.swappiness = 10

# Apply
sysctl -p

dirty_ratio controls how much memory can be filled with dirty pages before blocking writers. Increasing it from the default 20% to 30% improves write throughput. dirty_background_ratio starts background writeback earlier (at 10% vs the default 10%) — keeping it proportional to dirty_ratio prevents write storms.

Optimization 4: Database-Specific Tuning

If your VPS runs a database, the storage configuration matters more than anything else:

• Separate data and logs — Place database data files on one volume and transaction logs on another. This doubles effective IOPS since reads/writes to each are mostly sequential.
• InnoDB buffer pool size — Set to 70-80% of available RAM for MySQL/MariaDB. This minimizes disk reads by keeping hot data in memory.
• WAL (Write-Ahead Log) on fast storage — For PostgreSQL, ensure the WAL directory is on the fastest storage available. WAL writes are synchronous — they block until the disk confirms the write.

When Provider Throttling Is the Problem

Sometimes, no amount of tuning will fix slow disk I/O because the provider is throttling your VPS at the hypervisor level. Signs of throttling:

• I/O performance consistently hits a ceiling regardless of workload type
• fio IOPS results match the provider's "burst" or "guaranteed" limits exactly
• Performance drops at regular intervals (token bucket refill cycles)
• Your neighbor's VPS on the same host is consuming all available I/O bandwidth

If throttling is confirmed, the only real solution is to upgrade to a plan with higher I/O limits or switch to a provider with less aggressive I/O throttling. See provider benchmarks to compare real-world disk I/O performance across VPS providers — the differences between providers at the same price point can be 5-10x.

Summary Checklist

1. Benchmark with fio — test 4K random IOPS, sequential throughput, and latency
2. Monitor with iostat under real workloads — watch for 100% utilization and high await times
3. Mount with noatime — simplest single optimization with measurable impact
4. Set the I/O scheduler to none for NVMe — let the hardware manage queue ordering
5. Tune sysctl parameters — dirty_ratio, swapiness, and vfs_cache_pressure
6. Separate database data and log volumes — doubles effective I/O capacity
7. Verify provider isn't throttling — compare fio results against advertised limits

Disk I/O optimization is a process, not a one-time fix. Benchmark your VPS when you first provision it, optimize based on the results, and re-benchmark after any configuration change. If you consistently can't achieve acceptable I/O performance, compare VPS hosting plans to find a provider that offers NVMe storage with higher I/O limits at your budget level.