Linux VPS Tuning: CPU Governors, Swappiness, and I/O Schedulers Explained with Real Configs

Your VPS boots with kernel defaults tuned for compatibility, not speed. The stock Linux configuration shipped with most provider images uses a conservative CPU frequency policy, a swap-heavy memory strategy, and an I/O scheduler designed for spinning disks from a decade ago. On a modern KVM or cloud instance those defaults translate into latency spikes exactly when you can least afford them: during a traffic burst, a database checkpoint, or a deploy. The fix is not a bigger plan — it is three kernel-level settings that take minutes to change: the CPU governor, vm.swappiness, and the block I/O scheduler.

Before you start, confirm what your instance actually exposes, because CPU frequency scaling and scheduler selection depend on the hypervisor and the block device your provider attached. If you are unsure which host gives you direct hardware control, our VPS comparison table lists CPU models, storage types, and virtualization modes across the major providers so you can match these tweaks to your hardware.

Step 1: Check Your Current Kernel Settings

Gather three values: the active CPU governor, the I/O scheduler for your root disk, and the current swappiness. All three are readable from sysfs and sysctl:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
cat /sys/block/vda/queue/scheduler
sysctl vm.swappiness vm.vfs_cache_pressure

On a typical Ubuntu or Debian image you will see powersave or ondemand for the governor, mq-deadline (or none on NVMe) for the scheduler, and vm.swappiness = 60. Each of those defaults is tuned for laptops and general-purpose desktops, not for a server that must answer requests quickly and predictably.

Step 2: Switch the CPU Governor to Performance

The governor decides how aggressively the CPU ramps its clock speed. powersave keeps cores at minimum frequency until load builds up, which adds hundreds of microseconds of ramp-up latency to every burst of work. The performance governor pins cores to their maximum frequency, trading a little idle power for consistent, low-latency response.

# Debian/Ubuntu
apt install linux-tools-common cpupower
cpupower frequency-set -g performance
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   # -> performance

To persist it across reboots on Debian/Ubuntu, set GOVERNOR="performance" in /etc/default/cpufrequtils and enable the service. Two caveats: on shared vCPU plans the host may override your governor, and on OpenVZ/LXC containers the cpufreq directory does not exist at all — if /sys/devices/system/cpu/cpu0/cpufreq is missing, skip this step and move on to memory and I/O.

Step 3: Tune Swappiness and the Page Cache

The default vm.swappiness = 60 tells the kernel to start moving anonymous pages to swap while plenty of RAM is still free. On a VPS with SSD-backed swap, aggressive swapping adds avoidable I/O and latency. For most web and database workloads a value between 5 and 15 is the sweet spot — swap becomes a safety net for genuine memory pressure instead of a routine part of operation.

sysctl -w vm.swappiness=10
sysctl -w vm.vfs_cache_pressure=50

# Persist:
cat > /etc/sysctl.d/99-vps-perf.conf <<'EOF'
vm.swappiness=10
vm.vfs_cache_pressure=50
EOF
sysctl --system

vm.vfs_cache_pressure=50 makes the kernel keep dentry and inode caches around longer, which speeds up repeated file access — exactly what a web server doing stat() calls all day needs. If your workload is mostly anonymous memory (Java, large in-memory caches), leave swappiness near 10; if you run a swapfile on a slow disk, consider 1.

Step 4: Pick the Right I/O Scheduler

The I/O scheduler reorders block requests to reduce seek time — a problem that barely exists on SSD and NVMe storage. On modern NVMe devices the none scheduler (called noop on older kernels) delivers requests straight to the hardware with zero overhead, and mq-deadline is a solid choice for SATA SSDs. The stock cfq-style defaults are gone on 6.x kernels, but mq-deadline is often still selected where none would be better.

# NVMe (vda/nvme0n1): bypass scheduling entirely
echo none > /sys/block/vda/queue/scheduler
# SATA SSD: deadline with short write expiry
echo mq-deadline > /sys/block/sda/queue/scheduler

# Persist with a udev rule:
cat > /etc/udev/rules.d/60-iosched.rules <<'EOF'
ACTION=="add|change", KERNEL=="vda", ATTR{queue/scheduler}="none"
EOF

Verify with cat /sys/block/vda/queue/scheduler. On multi-queue devices the setting applies per queue, so confirm the active scheduler in brackets, e.g. [none] mq-deadline.

Step 5: Measure the Difference

Tuning without measurement is guesswork. Run a quick CPU and I/O benchmark before and after, then compare p99 latency under load rather than averages:

# CPU events/sec (higher is better)
sysbench cpu --threads=4 --time=30 run

# Random read IOPS + latency percentiles
fio --name=randread --rw=randread --bs=4k --size=256M     --iodepth=32 --runtime=30 --time_based     --output-format=json | jq '.jobs[0].read'

# Latency spikes: watch steal + iowait under load
mpstat -P ALL 1

Typical results on a 2 vCPU KVM instance: the performance governor removes the frequency ramp-up tail from CPU-bound requests, swappiness tuning cuts swap-in stalls during memory pressure, and none on NVMe reduces random-read p99 latency by 10–30%. None of these changes require a reboot or a bigger plan — they are pure configuration wins.

When These Tweaks Do Not Apply

Container-based plans (OpenVZ, LXC, and some "cloud VPS" products) hide the kernel from you: cpufreq and scheduler sysfs entries are simply absent. On those plans your only lever is userspace — tuning PHP-FPM, the web server, and the database. If you are shopping for a plan where you own the kernel, see the full specs on the main site before you commit.

Conclusion

CPU governor, swappiness, and the I/O scheduler are the three highest-leverage kernel settings on a default VPS install. Together they cut latency spikes, reduce needless swap I/O, and let NVMe storage run at full speed. Apply them, benchmark before and after, and keep the changes in sysctl and udev so they survive reboots. If you want a host that gives you full kernel control at a budget price, InterServer's VPS line runs KVM with dedicated cores — worth a look once your current provider's limits start showing.

Note: the exact sysfs paths above assume a virtio block device (vda). On AWS-style nvme0n1 naming, substitute the device name accordingly.