{"id":221,"date":"2026-01-01T02:00:03","date_gmt":"2026-01-01T02:00:03","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=221"},"modified":"2026-09-18T22:03:10","modified_gmt":"2026-09-18T22:03:10","slug":"a-comprehensive-guide-to-linux-vps-virtual-private-server","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/a-comprehensive-guide-to-linux-vps-virtual-private-server\/","title":{"rendered":"Linux VPS Kernel Tuning: sysctl Parameters That Actually Improve Throughput"},"content":{"rendered":"\n

Most Linux VPS hosts hand you a box with a stock kernel and a generic sysctl<\/code> profile tuned for “average” hardware that doesn’t exist. If you run a busy web stack, a database, or a VPN endpoint, the default network buffers, file descriptor limits, and socket backlog values will throttle you long before your CPU maxes out. This guide walks through the kernel parameters that actually move the needle on a Linux VPS, in the order you should change them, with the reasoning behind each value so you can adapt it to your own workload instead of copy-pasting a random tuning script off a forum. For a look at which providers actually let you touch these settings, see our full VPS comparison<\/a>.<\/p>\n\n\n\n

Before you touch anything: baseline and back up<\/h2>\n\n\n\n

Every parameter you change should be justified by a measurement. Grab a baseline first, and keep a copy of the current config so you can roll back without a support ticket.<\/p>\n\n\n\n

# Snapshot current tunables\nsudo sysctl -a > ~\/sysctl-backup-$(date +%F).txt\n\n# Quick capability check\nnproc; free -m; ip -brief link\nsysctl net.core.somaxconn net.ipv4.tcp_congestion_control fs.file-max<\/code><\/pre>\n\n\n\n
Note the CPU count and available RAM. Tuning values scale with both \u2014 a socket buffer setting that’s generous on a 1 GB instance can be reckless on a 512 MB one, because the kernel allocates these buffers per-connection under load.<\/p>\n\n\n\n
Network stack: the highest-yield category<\/h2>\n\n\n\n
For most web-facing VPS workloads, the network stack is where you’ll see the clearest wins. Three settings matter most: the listen backlog, the TCP buffer autotuning ceiling, and the congestion control algorithm.<\/p>\n\n\n\n
Parameter<\/th>Default<\/th>Suggested<\/th>Why<\/th><\/tr><\/thead>
net.core.somaxconn<\/code><\/td>128<\/td>4096<\/td>Accept queue depth for busy listeners; 128 drops connections during spikes<\/td><\/tr>
net.ipv4.tcp_max_syn_backlog<\/code><\/td>128\u20131024<\/td>8192<\/td>Survives SYN floods and bursty client reconnects<\/td><\/tr>
net.core.rmem_max<\/code><\/td>212992<\/td>16777216<\/td>Caps autotuning; BDP on high-latency links needs big windows<\/td><\/tr>
net.core.wmem_max<\/code><\/td>212992<\/td>16777216<\/td>Same, for the send side<\/td><\/tr>
net.ipv4.tcp_congestion_control<\/code><\/td>cubic<\/td>bbr<\/td>Better throughput on lossy paths; see the tradeoffs below<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Apply them in a dedicated drop-in file rather than editing \/etc\/sysctl.conf<\/code>, so package updates and configuration management tools don’t stomp your work.<\/p>\n\n\n\n
sudo tee \/etc\/sysctl.d\/60-vps-network.conf >\/dev\/null <<'EOF'\nnet.core.somaxconn = 4096\nnet.ipv4.tcp_max_syn_backlog = 8192\nnet.core.rmem_default = 262144\nnet.core.wmem_default = 262144\nnet.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 262144 16777216\nnet.ipv4.tcp_wmem = 4096 262144 16777216\nnet.ipv4.tcp_slow_start_after_idle = 0\nnet.ipv4.tcp_mtu_probing = 1\nnet.ipv4.tcp_fin_timeout = 15\nEOF\nsudo sysctl --system<\/code><\/pre>\n\n\n\n
Should you switch to BBR?<\/h3>\n\n\n\n
BBR models the network path instead of reacting to packet loss, which helps a lot on paths with bufferbloat or mobile clients. It’s usually a net positive for content delivery and API traffic. The catch: BBR can be unfair to competing flows on a congested link and adds a little CPU overhead. On a 1-core VPS pushing heavy traffic, test before committing.<\/p>\n\n\n\n
sudo modprobe tcp_bbr\nsysctl net.ipv4.tcp_available_congestion_control\necho \"tcp_bbr\" | sudo tee \/etc\/modules-load.d\/bbr.conf\nsudo sysctl -w net.ipv4.tcp_congestion_control=bbr\nsudo sysctl -w net.core.default_qdisc=fq<\/code><\/pre>\n\n\n\n
File descriptors and process limits<\/h2>\n\n\n\n
“Too many open files” is the classic symptom of a VPS running an nginx + PHP-FPM or Node stack with defaults intact. The system-wide limit and the per-process limit are separate, and you need to raise both.<\/p>\n\n\n\n
sudo tee \/etc\/sysctl.d\/61-vps-files.conf >\/dev\/null <<'EOF'\nfs.file-max = 2097152\nfs.inotify.max_user_watches = 524288\nfs.inotify.max_user_instances = 8192\nEOF\nsudo sysctl --system\n\n# Per-service raises belong in the unit or the service conf, e.g. nginx:\n# echo \"worker_rlimit_nofile 65535;\" >> \/etc\/nginx\/nginx.conf\n\n# Verify at runtime\nulimit -n\ncat \/proc\/$(pgrep -o nginx)\/limits | grep 'open files'<\/code><\/pre>\n\n\n\n
Watch file-nr<\/code> under load to confirm you’re not approaching the ceiling: cat \/proc\/sys\/fs\/file-nr<\/code>. The third column is the maximum; if the first column is climbing toward it, raise fs.file-max<\/code> further.<\/p>\n\n\n\n
Memory management: swappiness and overcommit<\/h2>\n\n\n\n
On a VPS with limited RAM, the default vm.swappiness=60<\/code> encourages the kernel to page out anonymous memory early. For a database or cache-heavy workload, that’s a latency disaster. Lower it \u2014 but don’t set it to 0, which can cause the OOM killer to fire before swap is ever touched.<\/p>\n\n\n\n
sudo tee \/etc\/sysctl.d\/62-vps-memory.conf >\/dev\/null <<'EOF'\nvm.swappiness = 10\nvm.vfs_cache_pressure = 50\nvm.dirty_ratio = 15\nvm.dirty_background_ratio = 5\nvm.overcommit_memory = 1\nEOF\nsudo sysctl --system<\/code><\/pre>\n\n\n\n