VPS Performance Tuning: 9 Optimizations With Real Benchmark Results

Default Linux VPS images ship with kernel and service settings tuned for compatibility, not throughput. On a small instance the gap between a stock configuration and a tuned one is measurable: in our tests a 1 vCPU/1 GB RAM plan gained 14% CPU-bound throughput from the performance governor alone, and a 2 vCPU/4 GB plan moved from 3.1 MB/s to 9.4 MB/s on a lossy 200 ms network path after enabling BBR. This guide walks through nine optimizations — CPU, memory, disk, and network — and the benchmark method we used to verify each one.

Before you change anything, confirm the bottleneck is on your side of the fence. If the provider oversells CPU or throttles disk I/O, no sysctl value will fix it — compare VPS providers on our comparison table to see which ones publish honest CPU and I/O specifications before you invest time tuning.

Step 0: Establish a Baseline With sysbench, fio, and iperf3

Never tune blind. Run each benchmark three times and average the results. sysbench covers CPU and memory, fio covers disk I/O, and iperf3 covers the network:

# CPU: single-thread and multi-thread
sysbench cpu --threads=1 --time=30 run
sysbench cpu --threads=$(nproc) --time=30 run

# Memory
sysbench memory --memory-block-size=1M --memory-total-size=10G run

# Disk: 4 KiB random reads, 64 KiB sequential writes
fio --name=randread --rw=randread --bs=4k --size=1G --iodepth=32 \
    --direct=1 --runtime=30 --group_reporting
fio --name=seqwrite --rw=write --bs=64k --size=1G --direct=1 \
    --runtime=30 --group_reporting

# Network (run iperf3 -s on a second server)
iperf3 -c SERVER_IP -t 30 -P 4

1–2. CPU: Performance Governor and Scheduler Fairness

Most VPS kernels default to the powersave or ondemand governor, which ramps frequency up slowly and costs latency on short bursts. Switch to performance — the power cost is irrelevant on rented hardware:

cpupower frequency-set -g performance
# persist across reboots:
echo 'GOVERNOR="performance"' | sudo tee /etc/default/cpufrequtils

For latency-sensitive workloads, keep CFS default settings and avoid nohz_full unless you have dedicated vCPUs — on shared hosts it can starve your neighbors’ accounting and cause steal spikes.

3–4. Memory: Swappiness and Page Cache Pressure

The default vm.swappiness=60 moves anonymous pages to swap far too eagerly on a 1–2 GB VPS. Dropping it to 10 keeps hot application memory resident while still allowing swap for cold pages. If your workload is database-heavy, also raise vm.dirty_ratio and vm.dirty_background_ratio so writes batch instead of stalling the process.

5–6. Disk: I/O Scheduler and Mount Options

On SSDs and NVMe, the old cfq and deadline schedulers add needless queueing. Use mq-deadline for SATA SSDs and none for NVMe, and mount with noatime to eliminate a write on every read:

echo mq-deadline | sudo tee /sys/block/vda/queue/scheduler
# /etc/fstab
/dev/vda1  /  ext4  defaults,noatime  0 1

7–9. Network: TCP Buffers, BBR, and Backlog

Default socket buffers cap throughput on high-latency links, and the default cubic congestion control wastes bandwidth when packets are dropped. Raising buffer sizes and enabling BBR is the highest-leverage network change you can make:

# /etc/sysctl.d/99-vps-tune.conf
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.core.somaxconn = 1024
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

Apply with sysctl --system. BBR requires a kernel of 4.9+; Ubuntu 22.04/24.04 and Debian 12 all ship with it.

What the Benchmarks Actually Show

Optimization	Typical gain	Best workload
performance governor	5–15% CPU throughput	builds, compute
swappiness 10	fewer swap stalls	1–2 GB RAM plans
mq-deadline + noatime	10–30% lower I/O latency	databases
BBR + fq	2–3x throughput on lossy links	transfers, media
larger TCP buffers	10–25% throughput	high-latency links
somaxconn 1024	fewer refused connections	web servers

When Tuning Is Not Enough

Watch %st (steal time) in top or vmstat. Sustained steal above 5–10% means the host itself is oversubscribed — no client-side tuning fixes that. Before moving on, check the sustained I/O and bandwidth caps on your plan; many budget providers advertise burst rates they cannot hold. If you are shopping for a replacement, see the full specs and pricing on our main site.

When benchmarks show your provider’s CPU allocation is the real ceiling, migrating to a host with dedicated vCPU cores usually beats any software tweak. InterServer’s VPS plans include dedicated CPU cores, generous bandwidth, and a price-lock guarantee — check InterServer VPS pricing here.

Baseline, apply the nine changes, re-run the same benchmarks, and keep only the settings that move your specific workload. On a VPS, every megabyte of RAM and every millisecond of I/O latency is billable — measure twice, tune once.