Linux VPS I/O Scheduler and Disk Tuning: Choosing the Right Scheduler for Database and Web Workloads

The I/O scheduler on your Linux VPS determines how the kernel queues and dispatches block device requests. The default scheduler chosen by your distribution may not be optimal for your workload — especially on a virtualized environment where the underlying storage is already managed by the hypervisor. This guide explains how to select, switch, and tune I/O schedulers for database and web server workloads on a KVM or XEN VPS, and how to benchmark the results.

If you’re provisioning a new server for a performance-sensitive workload, start by reviewing our top-rated VPS providers for database and web workloads.

I/O Scheduler Options in Modern Linux

Since kernel 5.0, the Linux block layer offers three multi-queue (blk-mq) schedulers: none, mq-deadline, and bfq. A fourth option, kyber, is available in some distributions compiled with CONFIG_BLK_CGROUP_IOCOST. The legacy single-queue schedulers (deadline, cfq, noop) are deprecated and only available on older kernels or hardware without blk-mq support.

none

Passes requests directly to the block device with no reordering or merging. This is the recommended choice for NVMe drives and virtual disks where the hypervisor or the physical storage controller handles scheduling. Many cloud providers (AWS, DigitalOcean, Linode) recommend none for their virtualized environments because the host hypervisor already manages I/O ordering.

mq-deadline

Enforces per-request deadlines to prevent starvation while maintaining a good balance of throughput and latency. Read requests are given priority over writes, which benefits database workloads (MySQL, PostgreSQL) where read latency is critical. This is the default scheduler on many distributions for rotational and SATA SSD storage.

bfq (Budget Fair Queuing)

Allocates I/O time slices per process, ensuring that no single process monopolizes disk access. Best suited for shared hosting environments, desktops, or any scenario where multiple processes compete for disk I/O and you need fairness guarantees. Bfq adds CPU overhead compared to none or mq-deadline, so it is not ideal for high-throughput database servers.

kyber

A latency-optimized scheduler that uses a token-based admission policy to maintain target read and write latencies. Kyber is a good middle ground for latency-sensitive applications like web servers and real-time systems, but it is less widely tested on VPS platforms than none or mq-deadline.

Choosing the Right Scheduler for Your Workload

The choice depends on three factors: the storage hardware type, the workload pattern, and the virtualization layer.

Workload	Recommended Scheduler	Rationale
Database (MySQL, PostgreSQL, MariaDB)	none or mq-deadline	Databases benefit from low read latency. mq-deadline prioritizes reads; none passes through to NVMe which handles its own scheduling.
Web server (Nginx, Apache, static files)	none	Web servers serve many small files concurrently. No scheduler overhead maximizes throughput on NVMe/virtual disks.
Shared hosting / multi-tenant	bfq	Fairness ensures one tenant’s disk-heavy process does not starve others.
Real-time / low-latency applications	kyber or none	Kyber targets specific latency thresholds; none adds zero scheduling delay.
Legacy spinning HDD	mq-deadline	Deadline reduces seek times by reordering requests. Rare on modern VPS platforms.

How to Check and Change the I/O Scheduler

Check the Current Scheduler

# Check the scheduler for each block device
cat /sys/block/sda/queue/scheduler

# Example output on Ubuntu 22.04 with kernel 6.2:
# [mq-deadline] none kyber  bfq  (mq-deadline is currently active)

The brackets indicate the currently active scheduler. The list shows all available schedulers compiled into the kernel.

Change the Scheduler at Runtime

# Switch to 'none' for maximum performance on NVMe/virtual disks
echo none | sudo tee /sys/block/sda/queue/scheduler

# Switch to mq-deadline for database workloads
echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler

Make the Change Permanent

To persist the scheduler across reboots, add a udev rule or a systemd service:

# Create a udev rule for block devices
echo 'ACTION=="add|change", KERNEL=="sd*", ATTR{queue/scheduler}="none"' | sudo tee /etc/udev/rules.d/60-iosched.rules

# Apply immediately
sudo udevadm control --reload-rules && sudo udevadm trigger

Additional Disk Tuning Parameters

Beyond the scheduler, several sysfs knobs affect disk I/O performance:

# Increase the read-ahead buffer for sequential workloads (e.g., file serving)
sudo blockdev --setra 4096 /dev/sda

# Adjust the number of requests in the queue (higher = more throughput, higher latency)
echo 512 | sudo tee /sys/block/sda/queue/nr_requests

# Set the I/O priority for a specific process (e.g., database)
sudo ionice -c 2 -n 0 -p $(pgrep mysqld)

Benchmarking I/O Performance

Always benchmark after changing the scheduler to verify the impact on your workload:

# Install fio
sudo apt install fio -y

# Random read test (database-like workload)
fio --name=randread --rw=randread --bs=4k --size=1G --runtime=30 --iodepth=32 --direct=1

# Sequential read test (web/file server workload)
fio --name=seqread --rw=read --bs=1M --size=1G --runtime=30 --direct=1

Run these tests with each scheduler candidate and compare the IOPS and latency results. On a typical KVM VPS with NVMe storage, the none scheduler yields 5-10% higher IOPS than mq-deadline, while mq-deadline provides slightly better worst-case latency guarantees.

Conclusion

For most modern VPS deployments running on NVMe or virtualized SSD storage, the none scheduler is the optimal choice because it eliminates unnecessary kernel overhead. For database workloads where read latency is critical, mq-deadline provides a safety net against request starvation. Use the benchmarking commands above to verify the impact of your choice, and make the change permanent via a udev rule to ensure it survives reboots.

Ready to deploy your optimized VPS? Compare VPS providers with the best I/O performance to find a plan that matches your workload requirements.