{"id":764,"date":"2026-08-01T02:24:56","date_gmt":"2026-08-01T02:24:56","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=764"},"modified":"2026-08-01T02:24:56","modified_gmt":"2026-08-01T02:24:56","slug":"linux-io-scheduler-tuning-database-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/linux-io-scheduler-tuning-database-vps\/","title":{"rendered":"How to Tune the Linux I\/O Scheduler for Database Workloads on a VPS"},"content":{"rendered":"\n

The Linux I\/O scheduler decides the order in which block-device requests are processed, and on a VPS it is one of the most misunderstood performance levers in the kernel. Database workloads are especially sensitive to it: the difference between the wrong scheduler and the right one can show up as 20\u201340% swings in random-read latency, which translates directly into slower queries and higher p99 response times. This article explains how to pick, apply, and verify the I\/O scheduler for database workloads on a VPS.<\/p>\n\n\n\n

First, Know What You Are Running On<\/h2>\n\n\n\n

The modern kernel ships with four schedulers: mq-deadline<\/strong> (default on many distros), bfq<\/strong>, kyber<\/strong>, and none<\/strong> (a no-op pass-through). Critically, on NVMe and most cloud block storage the hardware already performs its own reordering and queueing, so a software scheduler can add overhead without adding benefit. Check what is active with:<\/p>\n\n\n\n

cat \/sys\/block\/vda\/queue\/scheduler\nlsblk -d -o NAME,ROTA<\/code><\/pre>\n\n\n\n
ROTA=0<\/code> means the device is non-rotational (SSD\/NVMe); ROTA=1<\/code> means a spinning disk. That single value determines your starting point. On cloud VPS instances backed by network storage, the physical device is often a remote SAN or NVMe array, which changes the calculus again.<\/p>\n\n\n\n
Which Scheduler for Which Workload<\/h2>\n\n\n\n
Scheduler<\/th>Best for<\/th>Why<\/th><\/tr><\/thead>
none<\/td>NVMe, cloud block storage, single-queue devices<\/td>Zero overhead; hardware already optimizes ordering<\/td><\/tr>
mq-deadline<\/td>SSD with mixed read\/write workloads<\/td>Guarantees read and write deadlines, limits starvation<\/td><\/tr>
bfq<\/td>HDD, shared disks, desktop-class latency fairness<\/td>Fairness-oriented; strong for many concurrent processes<\/td><\/tr>
kyber<\/td>Low-latency latency-sensitive apps on fast storage<\/td>Targets read\/write latency directly, minimal tuning<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
For a typical PostgreSQL or MySQL workload on an SSD-backed VPS, the practical choice is none<\/code> or mq-deadline<\/code>. On NVMe, none<\/code> is almost always right. On a shared or spinning-disk VPS (increasingly rare), bfq<\/code> prevents one noisy process from monopolizing the disk.<\/p>\n\n\n\n
Applying the Scheduler at Runtime<\/h2>\n\n\n\n
You can switch schedulers live, which makes A\/B testing easy:<\/p>\n\n\n\n
echo none > \/sys\/block\/vda\/queue\/scheduler<\/code><\/pre>\n\n\n\n
To make it permanent, add a udev rule so it survives reboots:<\/p>\n\n\n\n
# \/etc\/udev\/rules.d\/60-iosched.rules\nACTION==\"add|change\", KERNEL==\"vd*\", ATTR{queue\/scheduler}=\"none\"<\/code><\/pre>\n\n\n\n
If you use a kernel command-line parameter instead (elevator=none<\/code>), remember that it only applies to the boot device and is ignored for devices probed later. The udev approach covers all block devices consistently.<\/p>\n\n\n\n
Verify with Real Benchmarks, Not Opinions<\/h2>\n\n\n\n
Scheduler changes are workload-dependent, so benchmark before and after. fio<\/code> with a database-shaped profile is the right tool:<\/p>\n\n\n\n
fio --name=db-sim --rw=randrw --rwmixread=70 --bs=8k \\\n    --iodepth=16 --numjobs=4 --size=2G --runtime=60 \\\n    --time_based --group_reporting<\/code>\n\n\n\n
70% reads at 8 KB blocks approximates OLTP traffic. Record IOPS and latency percentiles under each scheduler. A meaningful difference is one you can reproduce across multiple runs \u2014 a 5% IOPS swing is noise; a 30% p99 latency change is real. For an even more realistic test, run your actual database's workload replay (pgbench<\/code> for PostgreSQL, sysbench oltp<\/code> for MySQL) and watch query latency directly.<\/p>\n\n\n\n
Interaction with Other I\/O Settings<\/h2>\n\n\n\n
The scheduler is only one layer of the I\/O stack. On a VPS, three adjacent knobs change the outcome:<\/p>\n\n\n\n