Disk speed: baseline and burst

Disk on a VPS is NVMe, but speed is limited by tier so that one machine doesn't eat up the shared resource of the node. Understanding these numbers saves you from the question “why is the database slow when the CPU is free”.

How it's calculated

The write baseline is 60 MB/s per core, but not lower than 60 and not higher than 400 MB/s. Read is twice the write baseline. Above the baseline, a burst of three times its value is available for 30 seconds.

The burst covers what it should: application startup, archive extraction, applying a migration. A steady write stream — copying gigabytes, a build, scanning a large database — runs at the baseline.

How to measure

sudo apt install -y fio
fio --name=w --rw=write --bs=1M --size=2G --numjobs=1 \
    --runtime=60 --time_based --end_fsync=1 --directory=/var/tmp

The first seconds will show a burst, then the speed will drop to the baseline — this is the normal and expected picture, not a fault.

A quick rough check without installing packages:

dd if=/dev/zero of=/var/tmp/testfile bs=1M count=2048 oflag=direct
rm /var/tmp/testfile

Don't run disk tests on a production machine during working hours. The test will genuinely consume the entire available bandwidth, and your site will take seconds to respond during those minutes. And don't leave test files behind: two gigabytes on a 40 GB disk is a noticeable share, see disk space.

How to tell that the disk is the bottleneck

sudo apt install -y sysstat
iostat -x 2 5
vmstat 2 5

Look at two metrics: %util close to 100 and await in the tens of milliseconds indicate a disk queue. In vmstat the sign is the same — a growing b column (processes waiting) with a low CPU utilization percentage.

Another symptom: high load average with an almost idle CPU. Linux load average also counts processes waiting for the disk.

Who exactly is writing:

sudo iotop -o -b -n 3

What to do if you've hit the bottleneck

• Stagger them in time. Copies, registry builds, reports — at night and not at the same time. See scheduled jobs.
• Limit background tasks. rsync --bwlimit, nice -n 19 ionice -c3 <command> for everything that isn't urgent.
• Reduce writes. Limit log size, disable excessive verbosity in the application, move the cache to memory (tmpfs) if it will survive a reboot.
• Tune the database. In PostgreSQL and MySQL, the lion's share of writes is the transaction log. More memory for buffers means fewer disk accesses.
• Move up a tier. The baseline grows with the cores: from VDS-1 to VDS-2 it doubles. Plan upgrades are only possible upward, with an additional payment for the remaining days of the paid term.

Common mistakes

• Measuring speed with dd without oflag=direct. Data settles in the page cache, and the numbers come out inflated.
• Treating a burst as sustained speed. The first 30 seconds are fast, then the baseline — this is by design.
• Keeping swap on the active disk and swapping into it. When memory is short, swap turns the disk into a bottleneck: better to limit containers, see resource limits.