Kernel tuning for performance

The sysctls that actually move the needle.

With the kernel-as-files model understood, performance tuning is choosing the right sysctls for a workload — but the honest lesson is that most default settings are good, and the wins come from a small number of parameters that match your specific bottleneck, not from pasting a giant list. The method is the same as all performance work: measure first (USE method), identify the constrained resource, change one relevant tunable, and measure again. Tuning without measurement is just changing numbers.

Memory and swap behavior

A couple of memory tunables genuinely matter. vm.swappiness controls how eagerly the kernel swaps out memory to reclaim it for cache — the default (60) is fine for desktops but often too high for servers with plenty of RAM, where a lower value (10, or even 1) keeps application memory resident and avoids latency spikes from swapping. vm.dirty_ratio governs how much modified data buffers before being forced to disk, which affects write-heavy workloads. These are the memory sysctls worth understanding before touching.

vm.swappiness = 10            # prefer keeping app memory in RAM over swapping (server default)
vm.dirty_background_ratio = 5 # start flushing dirty pages sooner (smoother write bursts)
vm.dirty_ratio = 15           # hard cap on dirty pages before blocking writers

Network and file limits

For network-heavy servers, a few settings raise ceilings that default conservatively: the connection backlog (net.core.somaxconn) and buffer sizes matter for high-throughput or high-connection services, and fs.file-max plus per-process limits (ulimit -n) govern how many files and sockets a busy server can hold open — the classic "too many open files" error is this ceiling. These are raised deliberately for known high-load services, not blanket-applied.

$ ulimit -n                          # this shell’s open-file limit
1024
$ cat /proc/sys/fs/file-nr           # system-wide: allocated / free / max file handles
$ sysctl net.core.somaxconn          # the listen backlog (raise for high-connection servers)
net.core.somaxconn = 4096

The discipline that matters more than any setting

The single most valuable habit is to resist "optimization" you have not measured. A tuning change that helps one workload can hurt another, defaults encode a lot of hard-won sensible behavior, and a host full of copied-in sysctls nobody understands is a liability, not a fast server. Change one parameter with a hypothesis, benchmark before and after against your real workload, keep what demonstrably helps, and document why. Performance engineering is measurement with a little tuning attached — never the reverse.