If you cut your teeth on bare-metal servers, you remember the elevator tuning ritual: deadline for databases, noop for SSDs, BFQ for desktops. On a cloud VPS, that instinct mostly wastes your time \u2014 because the guest never sees a real disk. The I\/O scheduler in your VM’s kernel reorders requests that are about to be shoved through a virtual queue into a hypervisor that does the real scheduling. This article explains what the scheduler actually does on a virtio-blk device, when it still matters, and where your tuning effort belongs instead.<\/p>\n\n\n\n
lsblk -d -o NAME,ROTA,TRAN\n# NAME ROTA TRAN\n# vda 0 virtio\n\ncat \/sys\/block\/vda\/queue\/scheduler\n# [mq-deadline] none<\/code><\/pre>\n\n\n\nThree things jump out: the device is virtio<\/code> (a paravirtualized block device), it is non-rotational (ROTA 0<\/code>), and the default scheduler on modern kernels is mq-deadline<\/code> with none<\/code> as the alternative. There is no BFQ in sight unless your provider passes through a real NVMe controller \u2014 which is rare on budget and mid-range VPS plans.<\/p>\n\n\n\nWhy the guest scheduler barely matters<\/h2>\n\n\n\n
On a physical box, the scheduler’s job is to merge adjacent requests and reorder them to minimize head movement \u2014 a big deal for spinning disks, a smaller deal for SSDs. Inside a VM, in-flight requests are limited by the virtio ring (typically 128 entries), and the hypervisor performs merging and scheduling on the host side, where it sees the real storage. Your guest scheduler can only reorder the requests sitting in its own small queue, so its impact on total throughput is a few percent at most. Anyone promising large gains from switching a cloud VPS to none<\/code> is selling something.<\/p>\n\n\n\nThe one place the guest queue can bite is at very high queue depth: bulk imports, analytics jobs, or a database checkpoint writing hundreds of MB at once. If iostat<\/code> shows avgqu-sz<\/code> pinned at the queue limit with utilization near 100%, the guest queue \u2014 not the storage \u2014 is the bottleneck. That is the scenario where none<\/code> can shave a few percent of overhead.<\/p>\n\n\n\nThe levers that do exist<\/h2>\n\n\n\n
nr_requests<\/code><\/strong> controls how many requests the block layer queues per device. The default of 128\u2013256 is right for most workloads; lowering it to 64 can trim latency spikes when a noisy neighbor saturates the shared storage, and raising it almost never helps on virtio because the ring caps what can actually be in flight.<\/p>\n\n\n\niodepth<\/code><\/strong> is the parameter that actually moves numbers \u2014 but it belongs in your benchmark and your database configuration, not in \/sys<\/code>. A MySQL or PostgreSQL instance issuing depth-16 to depth-32 I\/O will behave completely differently from a depth-1 benchmark:<\/p>\n\n\n\nfio --name=randread --rw=randread --bs=4k --iodepth=32 \\\n --ioengine=libaio --direct=1 --runtime=60 --numjobs=4 --size=1G<\/code><\/pre>\n\n\n\nRun that once per scheduler to prove the point to yourself:<\/p>\n\n\n\n
for sched in none mq-deadline; do\n echo \"$sched\" > \/sys\/block\/vda\/queue\/scheduler\n fio --name=bench --rw=randread --bs=4k --iodepth=32 \\\n --ioengine=libaio --direct=1 --runtime=30 --size=512M \\\n | grep -E 'IOPS|lat'\ndone<\/code><\/pre>\n\n\n\nOn a typical virtio disk the IOPS difference lands inside the noise. If you do decide to change the scheduler, make it survive reboots with a udev rule:<\/p>\n\n\n\n
# \/etc\/udev\/rules.d\/60-iosched.rules\nACTION==\"add|change\", KERNEL==\"vd*\", ATTR{queue\/scheduler}=\"none\"\nsudo udevadm trigger<\/code><\/pre>\n\n\n\nHow to tell if the guest queue is even the bottleneck<\/h2>\n\n\n\n
Before you touch any knob, confirm the queue is the constraint. iostat -x 5<\/code> gives you the numbers that matter: avgqu-sz<\/code> (average queue length), %util<\/code> (how busy the device reports itself), and await<\/code> (average I\/O time including queueing). On a virtio disk with a 128-entry ring, avgqu-sz<\/code> pinned near 128 with %util<\/code> at 100% and await<\/code> climbing means requests are waiting in the guest \u2014 the point where scheduler and nr_requests<\/code> choices can shave latency. If instead avgqu-sz<\/code> stays low but await<\/code> is high, the storage backend is slow or throttled, and no guest-side setting will fix it \u2014 that’s a provider conversation, not a kernel one.<\/p>\n\n\n\nThe same separation applies to vmstat<\/code>: watch the b<\/code> column (processes blocked on I\/O). A few blocked processes during a checkpoint is normal; sustained double digits across all vCPUs points at the storage layer, and it’s worth re-running your fio baseline against the provider’s published numbers before you blame your config.<\/p>\n\n\n\nWhere to spend the tuning time instead<\/h2>\n\n\n\n
The scheduler is a five-minute check, not a tuning project. The real wins on cloud storage live in three places:<\/p>\n\n\n\n