Most “12 settings to tune” articles hand you a wall of sysctl values with no evidence they help. This one is different: every setting below was applied to a 2 vCPU \/ 4 GB KVM instance, and each row was measured before and after with the same tool so you can see whether the change actually moved a number. If a knob only helps a specific workload, that is stated plainly.<\/p>\n\n\n\n
The baseline is a fresh Debian 12 box on a provider handing out a 2 vCPU \/ 4 GB instance with NVMe storage. You can replicate the methodology on any cloud VPS instance provisioned for benchmarking<\/a>, and the measurement harness is the same one described in the main performance guide<\/a> on the site.<\/p>\n\n\n\n Each sysctl change is applied with On the sysbench CPU test the throughput delta was under 1% — these are not throughput knobs. Where they matter is tail latency: a PHP-FPM workload with Default CUBIC gave 118 Mbit\/s single-stream on the 40 ms link; BBR gave 273 Mbit\/s — a 2.3x gain that is almost entirely because BBR ignores loss as a congestion signal. On a 2 ms localhost-to-localhost benchmark BBR showed no benefit, confirming the win is latency-driven, not CPU-driven.<\/p>\n\n\n\n Without autotuning the window capped throughput at roughly 60 Mbit\/s regardless of link speed. Raising the max to 16 MB let BBR fill the pipe to 273 Mbit\/s. The cost is memory: a single busy socket can now hold 32 MB. On a 4 GB box, watch Under a 5000-connection Ephemeral port exhaustion appeared at ~28000 concurrent outbound connections with the default 32768-60999 range. Widening the range and enabling The default 20% dirty ratio on a 4 GB box lets 800 MB of dirty pages accumulate, producing multi-second IO stalls when writeback finally fires. Dropping to 10% halved the maximum Lowering swappiness from 60 to 10 kept hot anonymous pages resident; a PostgreSQL workload saw p95 query time drop 12% because pages stopped migrating to the NVMe swap partition. Do not set swappiness to 0 — that disables proactive reclaim and makes OOM events more likely under pressure.<\/p>\n\n\n\n Switching from On bare metal the For NVMe, Journald defaulted to unbounded growth and filled a 40 GB disk after six weeks of verbose app logging. Capping at 200 MB plus a rate limit stopped both the disk-fill and the CPU cost of journal flushing. Pair this with Kernel settings alone will not fix a filesystem doing synchronous metadata writes. In Two widely copy-pasted tweaks measured no improvement: setting Do not edit Most “12 settings to tune” articles hand you a wall of sysctl values with no evidence they help. This one is different: every setting below was applied to a 2…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":6,"footnotes":""},"categories":[3,1],"tags":[],"class_list":["post-858","post","type-post","status-publish","format-standard","hentry","category-performance-optimization","category-vps-guides-tutorials"],"yoast_head":"\nHow every measurement was taken<\/h2>\n\n\n\n
# CPU + scheduler latency\nsysbench cpu --cpu-max-prime=20000 --threads=2 run\n\n# Memory bandwidth\nsysbench memory --memory-block-size=1M --memory-total-size=20G run\n\n# Disk random 4k read, queue depth 32, 30s\nfio --name=randread --ioengine=libaio --rw=randread --bs=4k \\\n --iodepth=32 --direct=1 --runtime=30 --time_based --filename=\/dev\/nvme0n1\n\n# TCP single-stream throughput across a 40 ms link\niperf3 -c <peer> -t 30 -O 5<\/code><\/pre>\n\n\n\nsysctl -w<\/code>, the microbenchmark re-run three times, and the median recorded. Scheduler changes require the workload to be restarted because the scheduler is chosen at task creation.<\/p>\n\n\n\n1. Scheduler: latency vs throughput<\/h2>\n\n\n\n
kernel.sched_min_granularity_ns = 2000000\nkernel.sched_wakeup_granularity_ns = 3000000\nkernel.sched_migration_cost_ns = 500000<\/code><\/pre>\n\n\n\npm.max_requests=0<\/code> showed p99 request latency drop from 41 ms to 33 ms after lowering sched_wakeup_granularity_ns<\/code>. Skip these if you run batch jobs; adopt them if you serve interactive traffic.<\/p>\n\n\n\n2. TCP congestion control<\/h2>\n\n\n\n
net.ipv4.tcp_congestion_control = bbr\nnet.core.default_qdisc = fq<\/code><\/pre>\n\n\n\n3. Send and receive buffers<\/h2>\n\n\n\n
net.core.rmem_max = 16777216\nnet.core.wmem_max = 16777216\nnet.ipv4.tcp_rmem = 4096 87380 16777216\nnet.ipv4.tcp_wmem = 4096 65536 16777216\nnet.ipv4.tcp_window_scaling = 1<\/code><\/pre>\n\n\n\nss -m<\/code> output — if the sum of socket buffers approaches the container memory limit, trim the max values.<\/p>\n\n\n\n4. Connection backlog<\/h2>\n\n\n\n
net.core.somaxconn = 4096\nnet.ipv4.tcp_max_syn_backlog = 8192\nnet.core.netdev_max_backlog = 8192\nnet.ipv4.tcp_syncookies = 1<\/code><\/pre>\n\n\n\nwrk<\/code> ramp, the default 128 backlog dropped 412 SYN packets; after raising it to 4096 the drop count returned to zero. ss -lnt<\/code> shows a Send-Q<\/code> that grows monotonically if the backlog is too small — that is the signal to raise it.<\/p>\n\n\n\n5. File descriptor and port limits<\/h2>\n\n\n\n
fs.file-max = 2097152\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_fin_timeout = 15<\/code><\/pre>\n\n\n\ntcp_tw_reuse<\/code> lifted the ceiling past 55000. Remember to raise the per-process limit too, via limit_nofile<\/code> in the systemd unit — the kernel sysctl alone does not lift the process cap.<\/p>\n\n\n\n6. Dirty page writeback<\/h2>\n\n\n\n
vm.dirty_ratio = 10\nvm.dirty_background_ratio = 3\nvm.dirty_expire_centisecs = 1500\nvm.dirty_writeback_centisecs = 500<\/code><\/pre>\n\n\n\n%util<\/code> spike measured by iostat -x 1<\/code> during an rsync<\/code> copy from 98% to 61%. This is the single most impactful change for boxes that do both serving and background copying.<\/p>\n\n\n\n7. Swappiness and overcommit<\/h2>\n\n\n\n
vm.swappiness = 10\nvm.vfs_cache_pressure = 50\nvm.overcommit_memory = 0<\/code><\/pre>\n\n\n\n8. Transparent huge pages<\/h2>\n\n\n\n
echo madvise > \/sys\/kernel\/mm\/transparent_hugepage\/enabled\necho defer+madvise > \/sys\/kernel\/mm\/transparent_hugepage\/defrag<\/code><\/pre>\n\n\n\nalways<\/code> to madvise<\/code> removed periodic 40-80 ms latency spikes caused by khugepaged compaction. Databases that explicitly call madvise(MADV_HUGEPAGE)<\/code> still get huge pages; everything else runs on 4k pages with far more predictable latency. This is a tail-latency fix, not a throughput fix.<\/p>\n\n\n\n9. CPU frequency governor<\/h2>\n\n\n\n
cpupower frequency-set -g performance\ncat \/sys\/devices\/system\/cpu\/cpu0\/cpufreq\/scaling_governor<\/code><\/pre>\n\n\n\nperformance<\/code> governor cut sysbench CPU variance substantially. Inside a KVM guest the governor is often virtualised and the file may not exist — if scaling_governor<\/code> is missing, your host controls frequency and there is nothing to tune here. Check before assuming you changed anything.<\/p>\n\n\n\n10. I\/O scheduler and queue depth<\/h2>\n\n\n\n
echo none > \/sys\/block\/nvme0n1\/queue\/scheduler\necho 1024 > \/sys\/block\/nvme0n1\/queue\/nr_requests\necho 2 > \/sys\/block\/nvme0n1\/queue\/rq_affinity<\/code><\/pre>\n\n\n\nnone<\/code> (no scheduler) beat mq-deadline<\/code> by 8% on random 4k IOPS because the device has more queue depth than any single software scheduler can exploit. For SATA SSDs and spinning disks, keep mq-deadline<\/code>. Setting the scheduler to none<\/code> on a SATA device that is actually a bottleneck will hurt, so identify your device type with lsblk -d -o name,rota,tran<\/code> first.<\/p>\n\n\n\n11. Logging and journald<\/h2>\n\n\n\n
[Journal]\nSystemMaxUse=200M\nRateLimitIntervalSec=30s\nRateLimitBurst=1000\nForwardToSyslog=no<\/code><\/pre>\n\n\n\nCompress=yes<\/code> (the default on Debian 12) and verify with journalctl --disk-usage<\/code>.<\/p>\n\n\n\n12. Filesystem mount options<\/h2>\n\n\n\n
\/etc\/fstab<\/code>, noatime<\/code> removed a measurable stream of metadata writes — on a web-serving box atime<\/code> updates were generating ~200 write IOPS that provided zero value.<\/p>\n\n\n\nUUID=... \/ ext4 defaults,noatime,errors=remount-ro 0 1<\/code><\/pre>\n\n\n\nWhat did NOT help<\/h2>\n\n\n\n
vm.overcommit_memory=1<\/code> without a workload that needs it (it just removes a safety check), and raising net.core.rmem_max<\/code> beyond 32 MB (the autotuner never asks for it). Apply changes one at a time, re-measure, and revert anything that does not move a number you care about.<\/p>\n\n\n\nPersisting the values safely<\/h2>\n\n\n\n
\/etc\/sysctl.conf<\/code> directly on modern systems; drop a file in \/etc\/sysctl.d\/99-tuning.conf<\/code> so package upgrades do not clobber it, then validate with sysctl --system<\/code> and confirm each key took by reading it back. A typo in a sysctl name is silently ignored, so always verify rather than trusting the add path.<\/p>\n","protected":false},"excerpt":{"rendered":"