{"id":496,"date":"2026-06-23T06:51:42","date_gmt":"2026-06-23T06:51:42","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=496"},"modified":"2026-06-24T02:40:51","modified_gmt":"2026-06-24T02:40:51","slug":"vps-ssd-trim-maintenance-nvme-2","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/vps-ssd-trim-maintenance-nvme-2\/","title":{"rendered":"VPS Storage Performance: How to Benchmark and Optimize Disk I\/O on Your Server"},"content":{"rendered":"\n

Why Disk I\/O Performance Matters on a VPS<\/h2>\n\n\n\n

Storage I\/O is often the most contended resource on a virtual private server. While CPU and RAM are typically dedicated to your instance, disk I\/O is shared across the hypervisor’s storage subsystem. Poor I\/O performance leads to slow database queries, laggy web applications, and extended deployment times. This guide walks you through benchmarking your VPS disk I\/O with industry-standard tools, interpreting the results, and applying optimizations that make a measurable difference.<\/p>\n\n\n\n

The first step in any optimization journey is understanding your baseline. The quality of underlying storage varies significantly between VPS providers \u2014 those using NVMe with low oversubscription deliver dramatically better I\/O than older SATA SSD or HDD setups. Compare providers with transparent storage specs at virtualserversvps.com<\/a>.<\/p>\n\n\n\n

Benchmarking Tools: fio, hdparm, and dd<\/h2>\n\n\n\n

1. fio \u2014 The Gold Standard<\/h3>\n\n\n\n

fio<\/code> (Flexible I\/O Tester) is the most comprehensive disk benchmarking tool available for Linux. It supports customizable I\/O patterns, queue depths, block sizes, and concurrency. Install it with sudo apt install fio<\/code> and run these essential tests:<\/p>\n\n\n\n

Random 4K reads (IOPS test):<\/strong>
fio --name=randread --ioengine=libaio --iodepth=32 --rw=randread --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting<\/code><\/p>\n\n\n\n

Random 4K writes (IOPS test):<\/strong>
fio --name=randwrite --ioengine=libaio --iodepth=32 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=4 --runtime=60 --group_reporting<\/code><\/p>\n\n\n\n

Sequential 1M reads (throughput test):<\/strong>
fio --name=seqread --ioengine=libaio --iodepth=16 --rw=read --bs=1m --direct=1 --size=4G --numjobs=2 --runtime=60 --group_reporting<\/code><\/p>\n\n\n\n

Sequential 1M writes (throughput test):<\/strong>
fio --name=seqwrite --ioengine=libaio --iodepth=16 --rw=write --bs=1m --direct=1 --size=4G --numjobs=2 --runtime=60 --group_reporting<\/code><\/p>\n\n\n\n

Interpreting fio Results<\/h3>\n\n\n\n
Metric<\/th>Good (NVMe)<\/th>Fair (SATA SSD)<\/th>Poor (HDD)<\/th><\/tr><\/thead>
4K random read IOPS<\/td>>50,000<\/td>10,000\u201350,000<\/td><500<\/td><\/tr>
4K random write IOPS<\/td>>30,000<\/td>5,000\u201330,000<\/td><300<\/td><\/tr>
1M sequential read (MB\/s)<\/td>>1,000<\/td>300\u20131,000<\/td><150<\/td><\/tr>
1M sequential write (MB\/s)<\/td>>500<\/td>200\u2013500<\/td><100<\/td><\/tr>
Latency (4K random, \u00b5s)<\/td><200<\/td>200\u20131,000<\/td>>5,000<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

2. hdparm \u2014 Quick Cache\/Transfer Tests<\/h3>\n\n\n\n

hdparm<\/code> provides a quick buffered and cached read speed test. It’s useful for a rapid sanity check but doesn’t measure random I\/O or write performance, so take results with a grain of salt:<\/p>\n\n\n\n

sudo hdparm -Tt \/dev\/vda<\/code><\/p>\n\n\n\n

The -T<\/code> flag tests cached reads (RAM speed), and -t<\/code> tests buffered disk reads. On NVMe VPS, expect -t<\/code> results above 500 MB\/s. Values below 200 MB\/s suggest SATA SSD or significant hypervisor contention.<\/p>\n\n\n\n

3. dd \u2014 Simple Sequential Test<\/h3>\n\n\n\n

The classic dd<\/code> command can give a rough sequential throughput estimate. While not as precise as fio, it’s available on every Linux system:<\/p>\n\n\n\n

Write test:<\/strong>
dd if=\/dev\/zero of=.\/test bs=1M count=4096 conv=fdatasync status=progress<\/code><\/p>\n\n\n\n

Read test:<\/strong>
dd if=.\/test of=\/dev\/null bs=1M status=progress<\/code><\/p>\n\n\n\n

Note: dd<\/code> only measures sequential access. A provider with fast sequential reads but terrible random IOPS (common on shared HDD arrays) will look good in dd benchmarks but perform poorly under real database workloads.<\/p>\n\n\n\n

Optimizing Disk I\/O on Your VPS<\/h2>\n\n\n\n

1. Choose the Right I\/O Scheduler<\/h3>\n\n\n\n

The I\/O scheduler determines how the kernel orders and batches disk requests. For NVMe drives, the none<\/code> scheduler (multi-queue block layer) offers the lowest latency. For SATA SSDs, mq-deadline<\/code> provides a good balance. Check your current scheduler with cat \/sys\/block\/vda\/queue\/scheduler<\/code> and change it temporarily with echo none | sudo tee \/sys\/block\/vda\/queue\/scheduler<\/code>. Make it permanent via GRUB_CMDLINE_LINUX=\"elevator=none\"<\/code> in \/etc\/default\/grub<\/code>.<\/p>\n\n\n\n

2. Filesystem Selection and Mount Options<\/h3>\n\n\n\n

ext4<\/strong> is the default choice for most Linux VPS images. It’s stable, widely supported, and offers good performance with noatime<\/code> mount option to disable access time updates. Add defaults,noatime<\/code> to your \/etc\/fstab<\/code> mount options.<\/p>\n\n\n\n

XFS<\/strong> excels at large files and parallel I\/O. It’s the default on RHEL\/CentOS 8+ and offers better performance for workloads with many concurrent writers. Use mount options defaults,noatime,allocsize=1m<\/code> for database workloads.<\/p>\n\n\n\n

btrfs<\/strong> with Zstd compression can improve effective throughput for compressible data (text files, logs, source code). Use compress=zstd:3<\/code> mount option. However, btrfs has higher CPU overhead and is less battle-tested than ext4\/XFS on VPS.<\/p>\n\n\n\n

3. Tune the Block Layer<\/h3>\n\n\n\n

Several sysctl parameters affect I\/O performance. The most impactful are:<\/p>\n\n\n\n