VPS Performance Tuning: 10 sysctl Settings That Slash Latency and Boost Throughput

Most VPS providers hand you a generic Linux image with kernel defaults tuned for desktop machines, not servers. The good news: you do not need a bigger plan to get noticeably better performance. A handful of sysctl parameters — covering TCP buffers, file descriptors, swap behavior, and network queue sizes — routinely produce 20–40% throughput improvements on the same hardware. Here are the ten settings that matter most, with safe values for a typical 2–4 GB VPS.

If you are shopping for hardware at the same time, our VPS comparison table shows which providers give you honest CPU allocation and NVMe storage for the price.

Before You Tune: Benchmark Your Baseline

Always measure before and after. Two quick tools give you a baseline in under a minute:

# CPU: 4-thread sysbench run
sysbench cpu --threads=4 --time=30 run

# Network: iperf3 to a nearby server (run server side first: iperf3 -s)
iperf3 -c your-test-server -t 30

# Disk: sequential + random read
fio --name=seqread --rw=read --bs=1M --size=1G --numjobs=1 --runtime=30 --group_reporting

1–3. TCP Buffers and Congestion Control

Default TCP buffers are sized for low-latency home connections. On a VPS with 1 Gbps or faster uplinks, raising them lets the kernel fill the pipe:

# /etc/sysctl.d/99-vps-tune.conf
# TCP read/write buffer auto-tuning range (bytes)
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Enable BBR congestion control for high-throughput, low-latency paths
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

BBR is the single biggest win for servers that transfer large files or serve many concurrent clients — it typically cuts queueing latency by 20–50% on lossy paths. Verify it is active with sysctl net.ipv4.tcp_congestion_control (expect bbr).

4–5. File Descriptor and Connection Limits

Default file descriptor limits (1024 soft) cause mysterious “Too many open files” errors under load. Raise both the kernel limit and the per-process limit:

# Kernel-wide file descriptor limit
fs.file-max = 2097152

# Per-process soft limit (web server workers, databases)
fs.nr_open = 2097152

# Also add to /etc/security/limits.conf
# * soft nofile 1048576
# * hard nofile 1048576

6–7. Swap and Memory Management

Default vm.swappiness=60 pushes anonymous pages to swap too eagerly on a VPS where swap lives on the host’s disk. For databases and web servers, lower it so the kernel prefers to keep hot pages in RAM:

# Swap only under real memory pressure
vm.swappiness = 10

# Keep more dentries/inodes in cache instead of reclaiming aggressively
vm.vfs_cache_pressure = 50

# Avoid overcommitting memory beyond what is actually available
vm.overcommit_memory = 0

Setting	Default	VPS-tuned	Why
vm.swappiness	60	10	Less swap churn; hot pages stay in RAM
vm.vfs_cache_pressure	100	50	Fewer filesystem cache evictions
net.core.default_qdisc	pfifo_fast	fq	Fair queuing required for BBR
fs.file-max	~90000	2097152	Handles many concurrent connections
net.ipv4.tcp_rmem max	6 MB	16 MB	Larger receive windows for throughput

8–10. Network Queues and Timeouts

# Larger backlog for SYN requests (protects against SYN floods)
net.ipv4.tcp_max_syn_backlog = 65536

# Allow more time for connections in TIME_WAIT to be reused
net.ipv4.tcp_tw_reuse = 1

# Increase the network device queue length
net.core.netdev_max_backlog = 5000

Apply and Verify the Changes

# Apply immediately
sudo sysctl --system

# Verify key settings
sysctl net.ipv4.tcp_congestion_control
sysctl vm.swappiness
sysctl fs.file-max

Re-run your baseline benchmarks after applying. If throughput did not move, the bottleneck is elsewhere — CPU steal from an oversubscribed host, for example, which no sysctl setting will fix. When tuning cannot close the gap, compare VPS providers on our comparison table and look for plans with dedicated CPU cores and NVMe storage.

What NOT to Tune on a Shared VPS

CPU governor: On most KVM VPS instances the governor is already forced to performance by the host — changing it inside the guest has no effect.
NUMA settings: Guests usually see a single NUMA node; tuning numa_balancing can hurt more than help.
I/O scheduler: With virtio-blk or NVMe devices, the kernel often uses none/mq-deadline already — switching to bfq adds overhead without benefit.

Stick to the ten settings above, benchmark before and after, and you will get most of the performance headroom your plan can offer. For a full comparison of what different providers deliver out of the box, see our VPS performance comparison.