VPS Performance Tuning: 12 Settings Worth Checking in 2026

Most VPS plans arrive with kernel and application defaults tuned for a generic workload. On a small test box the defaults are fine; once real traffic arrives, a dozen small settings decide whether your server idles at 5% CPU or burns it fighting its own configuration. This is a practical checklist of twelve settings worth auditing on any production VPS in 2026, roughly in the order they usually matter. Each item takes minutes to check and most are one-line changes.

Memory and Swap

1. Swap size and swappiness

If your plan has no swap, add a 1–2 GB swapfile and set vm.swappiness to 10 so the kernel prefers RAM but can still relieve pressure. On small boxes, zram (compressed RAM swap) often beats a disk swapfile: sudo apt install zram-tools on Debian/Ubuntu. Verify with swapon --show and sysctl vm.swappiness.

2. Transparent Huge Pages (THP)

For database servers, THP in always mode causes allocation stalls and memory fragmentation. Set it to madvise: echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabled (make it persistent via a systemd tmpfiles rule). Web servers and app servers are usually fine either way.

Storage

3. I/O scheduler

NVMe drives should use none (or mq-deadline on older kernels); the old cfq adds needless latency. Check with cat /sys/block/vda/queue/scheduler and set it persistently with udev rules or a kernel boot parameter. On cloud VPS, the scheduler choice matters less than the IOPS cap on your plan.

4. Mount options

Remount filesystems with noatime to eliminate a write on every read: check mount | grep noatime and edit /etc/fstab. For SSD/NVMe, the discard option or a weekly fstrim cron keeps erased blocks available and write performance stable.

5. Filesystem choice

ext4 remains the safe default. XFS edges it out for large files and parallel writes; btrfs adds snapshots at some CPU cost. Reformatting is a big job, so only migrate if a benchmark — run with fio on both — shows a real gain for your workload. Compare providers side by side to see which offer NVMe storage at your price point before deciding whether to invest in tuning at all.

Network

6. TCP congestion control

Enable BBR if your kernel is 4.9+: set net.ipv4.tcp_congestion_control = bbr and net.core.default_qdisc = fq in /etc/sysctl.d/. On long-distance paths this is the single highest-impact network change you can make. See our guide on enabling BBR on your VPS for verification and rollback steps.

7. Socket buffers

For high-throughput transfers, raise net.core.rmem_max and net.core.wmem_max to 16 MB and let the TCP auto-tuning defaults handle the rest. Resist copying every sysctl guide on the internet — a handful of buffer and backlog settings covers 95% of cases, and aggressive values can waste RAM on small VPS plans.

8. Connection table and TIME_WAIT

Busy web servers exhaust net.ipv4.ip_local_port_range and the connection table faster than you expect. Widen the port range to 1024 65535, keep net.ipv4.tcp_fin_timeout at 30–60, and monitor ss -s for overflow. Do not enable tcp_tw_reuse blindly; test it under load first.

Application Stack

9. PHP-FPM pool sizing

Base pm.max_children on memory: roughly available RAM / average PHP process size. For a 2 GB box with 60 MB PHP processes that is about 30 children. Set pm = dynamic with sane start/max_spare values, enable opcache with opcache.memory_consumption=128, and check php-fpm8.2 -tt after edits. Oversized pools swap and stall; undersized pools queue requests.

10. Database and cache memory

Set InnoDB buffer pool to 60–70% of available RAM for MySQL/MariaDB: innodb_buffer_pool_size. For Redis, cap maxmemory at 70–80% of RAM with maxmemory-policy allkeys-lru so it never pushes the OS into swap. Both settings are single lines, and both are the most common cause of “server is slow but CPU is idle.”

11. Web server workers

Nginx: worker_processes auto; and worker_connections 1024; plus keepalive to upstreams. Apache: use mpm_event instead of prefork unless you need mod_php. Check nginx -t and reload, then watch uptime — if load average exceeds core count, the bottleneck is upstream, not the web server.

Operations

12. Logging, cron, and monitoring

Cap journald with SystemMaxUse=500M in /etc/systemd/journald.conf, keep logrotate running, and audit crontab entries: stagger jobs so backups and cert renewals do not collide, and prefix heavy jobs with nice -n 10 ionice -c3. Finally, install a monitoring agent — Netdata or Prometheus node_exporter — plus iostat and htop, so the next tuning pass starts from data instead of guesses. See the full specs and pricing on the main site if your current plan lacks the RAM or I/O headroom to make these settings pay off.

Quick Reference

Setting	Where	Typical value
Swappiness	/etc/sysctl.d/	vm.swappiness = 10
THP	kernel sysfs	madvise
I/O scheduler	queue sysfs / udev	none (NVMe)
Mount option	/etc/fstab	noatime
Congestion control	/etc/sysctl.d/	bbr + fq
Socket buffers	/etc/sysctl.d/	rmem_max/wmem_max = 16M
PHP-FPM	pool .conf	max_children = RAM/process size
InnoDB pool	my.cnf	60–70% of RAM
Redis maxmemory	redis.conf	70–80% of RAM
Journald cap	journald.conf	SystemMaxUse=500M

Bottom Line

Run through the checklist top to bottom once, record the before/after of free -h, iostat, and ss -s, then automate the checks with a monitoring tool so regressions surface early. The whole pass takes under an hour and typically buys 10–30% headroom on a small VPS. If the numbers still look tight after tuning, the plan itself may be undersized — compare providers side by side in our VPS comparison table before you upgrade.

Want a clean, current environment to apply these settings on? InterServer’s VPS plans include modern kernels and NVMe storage, with pricing that stays flat on renewal.