How to benchmark NVMe disk speed on a VPS
The first sign that your NVMe VPS is slowing down usually shows up as a database that suddenly feels sluggish, or an application that takes a second longer to boot. Before you blame the network or the CPU, measure the disk. Benchmarking NVMe disk speed on a VPS is a straightforward job with the right tools, and it takes about ten minutes once you know the commands. This guide walks you through a reproducible test suite using fio and dd on Ubuntu 24.04 LTS, explains how to read the numbers, and tells you what to expect from NVMe storage.
使用 fio 测试真实读写性能，避免被页面缓存误导。
Use fio to test real read and write performance instead of being misled by page cache.
Prerequisites
To run these benchmarks you need the following:
- A VPS running Ubuntu 24.04 LTS or Debian 12 (the commands work on any modern Linux distribution)
- Root access or a sudo user, since
fiotests need to write directly to a test file - At least 2 GB of free disk space, the test files are removed after each run
fioinstalled, which is not present on a fresh server by default
These benchmarks are purpose-built for a Linux VPS with full root access. If you run a Windows VPS, the equivalent tools are diskspd or winsat disk, but the methodology of testing sequential and random access remains identical.
Why benchmark disk speed on a VPS
NVMe is fast, but "fast" is not a number. The actual throughput and IOPS of your storage depends on the virtualization layer, the hypervisor, and how many neighbors share the same physical host. On enterprise virtualization such as KVM, the virtual disk controller and the allocated IOPS budget define what you get, not the sticker on the physical SSD.
That matters because your NVMe SSD VPS may show excellent sequential throughput yet deliver poor random IOPS. Databases run on random access, not sequential. If you host MySQL, PostgreSQL, or Redis, the random read and write IOPS figure is the one that predicts real-world performance. A sequential test alone will flatter the disk and hide the bottleneck.
There is a second reason to benchmark: verification. A cheap provider may provision your VPS on a shared SATA SSD while advertising NVMe. A quick fio run exposes the difference immediately, since NVMe sustains tens of thousands of IOPS, while SATA SSD typically delivers a few thousand. The gap is too large to hide.
Install the benchmarking tools
Start by updating the package index and installing fio, which is the industry-standard workload generator for storage benchmarking. The dd tool ships with coreutils, so it is already present.
sudo apt update
sudo apt install -y fioVerify the installation with:
fio --versionExpected output, which may vary slightly by version:
fio-3.42Version 3.42 is the current stable release as of mid-2026. If your distribution ships an older version, it still works fine, since the benchmark syntax used here is stable across several major releases.
Step 1 - Benchmark sequential read and write speed
Sequential throughput is the metric people usually mean by "disk speed". It measures how fast data moves when read or written in a continuous stream, which suits large file transfers, video processing, and database dumps.
Run this fio job to test both directions:
fio --name=seqread --rw=read --bs=1m --size=2g --iodepth=32 --numjobs=1 --direct=1 --group_reporting
fio --name=seqwrite --rw=write --bs=1m --size=2g --iodepth=32 --numjobs=1 --direct=1 --group_reportingSome explanations before you run it:
--direct=1bypasses the OS page cache, so the test measures the actual disk, not the RAM cache--bs=1muses 1 MiB blocks, the standard size for sequential tests--iodepth=32keeps 32 operations in flight, which lets a fast NVMe disk reach its peak throughput
Look at the BW line in the output, which reports bandwidth. A healthy NVMe disk on a decent VPS should show 1,000 to 2,000 MiB/s for both reads and writes. If your result is closer to 300-500 MiB/s, the storage is likely shared SATA SSD behind an enterprise virtualization layer.
For a quick sanity check, you can use dd instead, though the result is less precise because dd does not control for page cache the same way:
dd if=/dev/zero of=/tmp/testfile bs=1M count=2048 oflag=direct conv=fdatasync
rm /tmp/testfileThe oflag=direct flag avoids the cache, and conv=fdatasync forces the write to physically reach the disk before reporting. The last line prints something like "2147483648 bytes copied, 1.2 s, 1789 MB/s". That number is the raw sequential write throughput.
Step 2 - Benchmark random read and write IOPS
Random IOPS is the metric that predicts database performance. This test reads and writes 4 KiB blocks at random offsets, which mirrors how MySQL or PostgreSQL actually hit the disk.
fio --name=randread --rw=randread --bs=4k --size=2g --iodepth=32 --numjobs=4 --direct=1 --group_reporting
fio --name=randwrite --rw=randwrite --bs=4k --size=2g --iodepth=32 --numjobs=4 --direct=1 --group_reportingWhat changes here:
--bs=4kuses the 4 KiB block size typical of database pages--numjobs=4runs four parallel processes to simulate a busy server--iodepth=32keeps the queue full, which is what NVMe needs to shine
In the output, the IOPS column is the headline number. A well-provisioned NVMe VPS should deliver 30,000 to 80,000 read IOPS and 20,000 to 50,000 write IOPS. Consumer NVMe drives reach higher, but on a VPS you pay for a slice of a shared physical SSD, so the numbers reflect a fair partition.
If your random read IOPS sits below 10,000, something is wrong. Either the disk is heavily shared with noisy neighbors, or the provider provisioned SATA SSD. At that level, moving a database workload to a better-provisioned NVMe VPS hosting Vietnam with dedicated resources is a clear win.
Step 3 - Measure read and write latency
Throughput and IOPS tell you how much data the disk can move, but latency tells you how responsive it is. For a single database query, latency is what the user waits on. High IOPS with poor latency means a busy but sluggish disk.
Run the same random read test with a queue depth of one to simulate a single request:
fio --name=latency --rw=randread --bs=4k --size=200m --iodepth=1 --numjobs=1 --direct=1 --group_reportingWith --iodepth=1, the disk only ever has one request in flight, so the reported latency is the pure response time. Look at the lat (usec) section. A good NVMe disk under this test shows an average latency of 100 to 300 microseconds for reads. Values above 1 millisecond (1,000 microseconds) indicate the disk is contended or the storage layer has significant overhead.
This single-queue test is the one that matters for latency-sensitive workloads like Redis, which can serve from memory but still spills to disk during persistence. If latency is poor, the application feels slow even when throughput looks fine.
Step 4 - Compare the results against expectations
The point of benchmarking is to get a number you can judge. Here is a rough scale based on what shared virtualized NVMe typically delivers on a mid-range VPS pricing tier:
| Metric | SATA SSD | NVMe SSD |
|---|---|---|
| Sequential read | 200-500 MiB/s | 1,000-2,000 MiB/s |
| Random read IOPS | 3,000-8,000 | 30,000-80,000 |
| Random write IOPS | 2,000-5,000 | 20,000-50,000 |
| Read latency (QD1) | 300-800 usec | 100-300 usec |
These are typical ranges, not guarantees. A heavily loaded host can push NVMe down into SATA territory, which is why running the test a few times at different hours gives a better picture than a single run. If the numbers are consistently poor, the disk is the bottleneck and a larger plan with more dedicated resources is justified.
Note that figures vary with the size of the test file too. A 2 GiB test with --size=2g is a solid compromise between accuracy and time. A smaller file, like 512 MiB, may be partially served from the controller cache and flatter the result. A larger file, like 8 GiB, punishes the drive more but takes longer and writes more data to the storage pool.
Troubleshooting common benchmark issues
The first issue you will meet is an error about insufficient memory. fio with --size=2g and --iodepth=32 allocates buffers and some 2 GB RAM VPS plans cannot hold them all together with the running OS. Reduce the file size to --size=1g or lower the --numjobs to 2 and rerun.
A second issue is benchmarking the wrong filesystem. If your VPS has a separate partition for /var/lib/mysql or /home, run the test from inside that directory, not only from /root. The storage layer may be identical, but mounted volumes at different paths can point to different backend storage pools on some providers.
Check that direct=1 actually applies. Some filesystems, like tmpfs, ignore the direct flag because they have no underlying disk. Confirm your working directory is on a real disk with df -h . and verify the filesystem type. If it says tmpfs, move to /root or /var/tmp.
Finally, clean up the test files. fio deletes its own files by default, but the dd test leaves a file behind. Remove it to avoid filling the disk:
ls -lh /tmp/testfile
rm -f /tmp/testfileFAQ
What is the fastest way to benchmark NVMe disk speed on a VPS?
The fastest reliable method is a single fio job that tests sequential and random access. Run fio --name=test --rw=read --bs=1m --size=1g --iodepth=32 --direct=1 for throughput, then the same command with --rw=randread --bs=4k for IOPS. Two runs take under a minute and cover the metrics that matter.
Why does my dd benchmark show a faster speed than fio?
dd without oflag=direct reads from the OS page cache, which is RAM-speed, not disk-speed. Even with oflag=direct, dd uses a sequential pattern and a shallow queue, which flatters the disk. fio with --direct=1 and a proper iodepth gives a more honest number.
What is a good NVMe speed on a VPS?
Expect 1,000 to 2,000 MiB/s for sequential reads and 30,000 to 80,000 random read IOPS on a healthy NVMe VPS. If you see sequential speeds under 500 MiB/s or IOPS under 10,000, the storage is very likely shared SATA SSD, not NVMe.
Does benchmarking the disk wear out my VPS storage?
A quick benchmark writes a few GB of test data, which is negligible for the lifetime of an SSD. NVMe drives are rated for hundreds of terabytes written. The test files are deleted after the run, so you leave no lasting footprint beyond normal wear.
How often should I benchmark my VPS disk?
Run the benchmark when you first provision the server as a baseline, then again if you notice performance degradation. Periodic testing, like monthly, is useful to catch a noisy-neighbor problem early. There is no need to benchmark every day, since a single run is a snapshot, not a trend.
Related articles
- VPS performance benchmarking with fio, sysbench, and iperf3
- How to optimize MariaDB on a 2 GB RAM VPS
- Configure swap and optimize memory on a low RAM VPS
VPS 磁盘基准测试要点
用 fio 测试 VPS 的 NVMe 磁盘速度，重点看随机读写 IOPS 和延迟，而不是只测顺序吞吐。务必使用 direct=1 绕过页面缓存，否则结果虚高。单队列延迟测试能反映数据库的真实响应速度。如果结果低于 SATA SSD 水平，说明存储资源可能被共享过多，可考虑升级到资源更充裕的 NVMe VPS 套餐。
