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.<\/p>\n\n\n\n
If your plan has no swap, add a 1\u20132 GB swapfile and set For database servers, THP in NVMe drives should use Remount filesystems with 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 \u2014 run with Enable BBR if your kernel is 4.9+: set For high-throughput transfers, raise Busy web servers exhaust Base Set InnoDB buffer pool to 60\u201370% of available RAM for MySQL\/MariaDB: Nginx: Cap journald with Run through the checklist top to bottom once, record the before\/after of vm.swappiness<\/code> 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<\/code> on Debian\/Ubuntu. Verify with swapon --show<\/code> and sysctl vm.swappiness<\/code>.<\/p>\n\n\n\n2. Transparent Huge Pages (THP)<\/h3>\n\n\n\n
always<\/code> mode causes allocation stalls and memory fragmentation. Set it to madvise<\/code>: echo madvise | sudo tee \/sys\/kernel\/mm\/transparent_hugepage\/enabled<\/code> (make it persistent via a systemd tmpfiles rule). Web servers and app servers are usually fine either way.<\/p>\n\n\n\nStorage<\/h2>\n\n\n\n
3. I\/O scheduler<\/h3>\n\n\n\n
none<\/code> (or mq-deadline<\/code> on older kernels); the old cfq<\/code> adds needless latency. Check with cat \/sys\/block\/vda\/queue\/scheduler<\/code> 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.<\/p>\n\n\n\n4. Mount options<\/h3>\n\n\n\n
noatime<\/code> to eliminate a write on every read: check mount | grep noatime<\/code> and edit \/etc\/fstab<\/code>. For SSD\/NVMe, the discard<\/code> option or a weekly fstrim<\/code> cron keeps erased blocks available and write performance stable.<\/p>\n\n\n\n5. Filesystem choice<\/h3>\n\n\n\n
fio<\/code> on both \u2014 shows a real gain for your workload. Compare providers side by side<\/a> to see which offer NVMe storage at your price point before deciding whether to invest in tuning at all.<\/p>\n\n\n\nNetwork<\/h2>\n\n\n\n
6. TCP congestion control<\/h3>\n\n\n\n
net.ipv4.tcp_congestion_control = bbr<\/code> and net.core.default_qdisc = fq<\/code> in \/etc\/sysctl.d\/<\/code>. On long-distance paths this is the single highest-impact network change you can make. See our guide on enabling BBR on your VPS<\/a> for verification and rollback steps.<\/p>\n\n\n\n7. Socket buffers<\/h3>\n\n\n\n
net.core.rmem_max<\/code> and net.core.wmem_max<\/code> to 16 MB and let the TCP auto-tuning defaults handle the rest. Resist copying every sysctl guide on the internet \u2014 a handful of buffer and backlog settings covers 95% of cases, and aggressive values can waste RAM on small VPS plans.<\/p>\n\n\n\n8. Connection table and TIME_WAIT<\/h3>\n\n\n\n
net.ipv4.ip_local_port_range<\/code> and the connection table faster than you expect. Widen the port range to 1024 65535<\/code>, keep net.ipv4.tcp_fin_timeout<\/code> at 30\u201360, and monitor ss -s<\/code> for overflow. Do not enable tcp_tw_reuse<\/code> blindly; test it under load first.<\/p>\n\n\n\nApplication Stack<\/h2>\n\n\n\n
9. PHP-FPM pool sizing<\/h3>\n\n\n\n
pm.max_children<\/code> on memory: roughly available RAM \/ average PHP process size<\/code>. For a 2 GB box with 60 MB PHP processes that is about 30 children. Set pm = dynamic<\/code> with sane start\/max_spare values, enable opcache<\/code> with opcache.memory_consumption=128<\/code>, and check php-fpm8.2 -tt<\/code> after edits. Oversized pools swap and stall; undersized pools queue requests.<\/p>\n\n\n\n10. Database and cache memory<\/h3>\n\n\n\n
innodb_buffer_pool_size<\/code>. For Redis, cap maxmemory<\/code> at 70\u201380% of RAM with maxmemory-policy allkeys-lru<\/code> 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.”<\/p>\n\n\n\n11. Web server workers<\/h3>\n\n\n\n
worker_processes auto;<\/code> and worker_connections 1024;<\/code> plus keepalive to upstreams. Apache: use mpm_event<\/code> instead of prefork unless you need mod_php. Check nginx -t<\/code> and reload, then watch uptime<\/code> \u2014 if load average exceeds core count, the bottleneck is upstream, not the web server.<\/p>\n\n\n\nOperations<\/h2>\n\n\n\n
12. Logging, cron, and monitoring<\/h3>\n\n\n\n
SystemMaxUse=500M<\/code> in \/etc\/systemd\/journald.conf<\/code>, 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<\/code>. Finally, install a monitoring agent \u2014 Netdata or Prometheus node_exporter \u2014 plus iostat<\/code> and htop<\/code>, so the next tuning pass starts from data instead of guesses. See the full specs and pricing on the main site<\/a> if your current plan lacks the RAM or I\/O headroom to make these settings pay off.<\/p>\n\n\n\nQuick Reference<\/h2>\n\n\n\n
Setting<\/th> Where<\/th> Typical value<\/th><\/tr><\/thead> Swappiness<\/td> \/etc\/sysctl.d\/<\/td> vm.swappiness = 10<\/td><\/tr> THP<\/td> kernel sysfs<\/td> madvise<\/td><\/tr> I\/O scheduler<\/td> queue sysfs \/ udev<\/td> none (NVMe)<\/td><\/tr> Mount option<\/td> \/etc\/fstab<\/td> noatime<\/td><\/tr> Congestion control<\/td> \/etc\/sysctl.d\/<\/td> bbr + fq<\/td><\/tr> Socket buffers<\/td> \/etc\/sysctl.d\/<\/td> rmem_max\/wmem_max = 16M<\/td><\/tr> PHP-FPM<\/td> pool .conf<\/td> max_children = RAM\/process size<\/td><\/tr> InnoDB pool<\/td> my.cnf<\/td> 60\u201370% of RAM<\/td><\/tr> Redis maxmemory<\/td> redis.conf<\/td> 70\u201380% of RAM<\/td><\/tr> Journald cap<\/td> journald.conf<\/td> SystemMaxUse=500M<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Bottom Line<\/h2>\n\n\n\n
free -h<\/code>, iostat<\/code>, and ss -s<\/code>, then automate the checks with a monitoring tool so regressions surface early. The whole pass takes under an hour and typically buys 10\u201330% headroom on a small VPS. If the numbers still look tight after tuning, the plan itself may be undersized \u2014 compare providers side by side in our VPS comparison table<\/a> before you upgrade.<\/p>\n\n\n\n