{"id":1099,"date":"2026-09-11T22:36:12","date_gmt":"2026-09-11T22:36:12","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1099"},"modified":"2026-09-11T22:36:12","modified_gmt":"2026-09-11T22:36:12","slug":"fio-dd-disk-io-benchmark-vps-throttling","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/fio-dd-disk-io-benchmark-vps-throttling\/","title":{"rendered":"Benchmarking VPS Disk I\/O with fio and dd: Reading IOPS, Latency, and Throttle Limits"},"content":{"rendered":"\n

Almost every “my VPS feels slow” ticket ends with a dd<\/code> test that says 1.2 GB\/s and proves nothing. This is a job-file-first approach to disk benchmarking that produces numbers you can actually act on: random IOPS at realistic queue depth, tail latency, and a repeatable way to catch storage throttling in the act.<\/p>\n\n\n\n

Why dd numbers are misleading<\/h2>\n\n\n\n
# the classic (and useless) test\ndd if=\/dev\/zero of=\/var\/tmp\/test bs=1M count=2048 conv=fdatasync\n# 2.0 GB copied (2147483648 bytes), 1.5 s, 1.3 GB\/s<\/code><\/pre>\n\n\n\n
That 1.3 GB\/s is the host page cache plus log buffer merging, not the device. dd<\/code> cannot issue parallel requests, cannot report latency percentiles, and cannot express a mixed read\/write pattern. It is still useful for exactly one thing: finding out whether a full disk will accept writes at all.<\/p>\n\n\n\n
Install fio and run a 60-second 4K random test<\/h2>\n\n\n\n
sudo apt update && sudo apt -y install fio\nmkdir -p \/var\/tmp\/fiotest\n\ncat > \/var\/tmp\/fiotest\/rand4k.fio <<'EOF'\n[global]\ndirectory=\/var\/tmp\/fiotest\nsize=2G\nruntime=60\ntime_based=1\ngroup_reporting=1\nlat_percentiles=1\npercentile_list=50:95:99:99.9\nnorandommap=1\nrandrepeat=0\n\n[randwrite-qd1]\nrw=randwrite\nbs=4k\niodepth=1\n\n[randwrite-qd32]\nrw=randwrite\nbs=4k\niodepth=32\nEOF\n\nsudo fio \/var\/tmp\/fiotest\/rand4k.fio<\/code><\/pre>\n\n\n\n
Reading the output<\/h2>\n\n\n\n
Metric<\/th>Example (good NVMe tier)<\/th>Example (throttled shared storage)<\/th><\/tr><\/thead>
randwrite 4k qd1 IOPS<\/td>18,000<\/td>420<\/td><\/tr>
randwrite 4k qd32 IOPS<\/td>96,000<\/td>1,900<\/td><\/tr>
clat p50 \/ p99<\/td>0.05 ms \/ 0.31 ms<\/td>2.3 ms \/ 41 ms<\/td><\/tr>
Sequential 1M read<\/td>3.1 GB\/s<\/td>210 MB\/s<\/td><\/tr>
IOPS at 90 s vs 5 s<\/td>-4%<\/td>-88%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Two rules of thumb: a healthy NVMe-backed plan keeps qd1 4K writes above 5,000 IOPS and p99 latency under 1 ms. If qd32 barely improves on qd1 (under 2x), the provider is capping queue depth or IOPS – parallelism is being queued artificially.<\/p>\n\n\n\n
Sequential and mixed workloads<\/h2>\n\n\n\n
cat > \/var\/tmp\/fiotest\/seq.fio <<'EOF'\n[global]\ndirectory=\/var\/tmp\/fiotest\nsize=4G\nruntime=45\ntime_based=1\ngroup_reporting=1\n[seqread]\nrw=read\nbs=1M\niodepth=8\n[mixed-70-30]\nrw=randrw\nrwmixread=70\nbs=16k\niodepth=16\nEOF\nsudo fio \/var\/tmp\/fiotest\/seq.fio --output-format=normal,terse<\/code><\/pre>\n\n\n\n
The mixed 70\/30 test is the closest single proxy for a database plus web server sharing one volume. If mixed IOPS is less than 40% of the pure-write figure, expect query latency to spike whenever a backup or image resize runs.<\/p>\n\n\n\n
Catching throttling in the act<\/h2>\n\n\n\n
Run the same job continuously and print a line per 10-second window. A flat curve means real capacity; a step down that never recovers means a token-bucket cap. The watchdog below logs the cliff with a timestamp.<\/p>\n\n\n\n
for i in $(seq 1 30); do\n  fio --name=watch --directory=\/var\/tmp\/fiotest --rw=randwrite --bs=4k \\\n      --iodepth=16 --size=1G --runtime=10 --time_based --group_reporting \\\n      --output-format=json 2>\/dev\/null | \\\n  python3 -c \"import json,sys;d=json.load(sys.stdin)['jobs'][0];print(f\\\"{__import__('time').strftime('%H:%M:%S')} iops={d['write']['iops']:.0f} p99={d['write']['clat_ns']['percentile']['99.000000']\/1e6:.2f}ms\\\")\"\ndone | tee \/var\/tmp\/fiotest\/ramp.log<\/code><\/pre>\n\n\n\n
Confirm a provider cap rather than a slow device by checking the accounting counters – container-based VPSes expose the throttle events directly:<\/p>\n\n\n\n
cat \/sys\/fs\/cgroup\/io.stat 2>\/dev\/null\ncat \/sys\/fs\/cgroup\/blkio\/*.throttle.io_service_bytes 2>\/dev\/null\niostat -x 5 3 | egrep 'Device|nvme|vda|sda'<\/code><\/pre>\n\n\n\n
Pick the test that matches your workload<\/h2>\n\n\n\n
Workload<\/th>fio parameters<\/th>Metric to watch<\/th><\/tr><\/thead>
MySQL \/ PostgreSQL OLTP<\/td>randrw, bs=16k, rwmixread=70, iodepth=32<\/td>p99 clat<\/td><\/tr>
Redis AOF or WAL-heavy writes<\/td>write, bs=4k, iodepth=1, fsync=1<\/td>IOPS at qd1<\/td><\/tr>
Backup and log shipping<\/td>write, bs=1M, iodepth=8<\/td>sustained MB\/s<\/td><\/tr>
Static file serving<\/td>randread, bs=128k, iodepth=16<\/td>MB\/s and CPU cost<\/td><\/tr>
Container image pulls<\/td>randread, bs=1M, numjobs=4<\/td>aggregate MB\/s<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Add --fsync=1<\/code> for database-style writes and the numbers will fall sharply on consumer-grade storage. That gap between buffered and fsync throughput is frequently larger than the difference between two hosting tiers, which is exactly why a single buffered test can lead you to the wrong conclusion.<\/p>\n\n\n\n
Turn the numbers into a decision<\/h2>\n\n\n\n