Part 8 · 1 chapters · ~8 min
Tuning
Tuning as an experiment, the order of wins (eliminate work, then application, then runtime, then OS, then hardware), common Linux settings with their trade-offs (somaxconn, file descriptors, swappiness, dirty ratios, TCP buffers, BBR, transparent huge pages, CPU governor), and recording decisions.
9
Settings with reasons
| setting | when it matters | caution |
|---|---|---|
| net.core.somaxconn, listen backlog | ListenOverflows under bursts | the app's backlog argument must also rise |
| ulimit -n (nofile) | EMFILE with many connections | set in systemd unit or container runtime |
| vm.swappiness | latency-sensitive services swapping | low values, not necessarily 0 |
| vm.dirty_ratio / background | write stalls from large flushes | smaller values smooth writeback |
| net.ipv4.tcp_congestion_control=bbr | long or lossy paths | test; pair with fq qdisc |
| transparent huge pages | some databases recommend madvise or never | follow the database's guidance (Redis warns about THP) |
| CPU governor = performance | latency spikes from frequency scaling | costs power |
Order of wins: remove unnecessary work (characterisation), fix the application (algorithms, queries, caching), tune the runtime (GC, pools), then the OS, then buy hardware. Kernel tuning rarely rescues an N+1 query.
TUNING, ONE CHANGE AT A TIME
the loop that prevents folklore
swipe the figure sideways, or tap expand for full screen
1/4
baseline
Measure the metric that matters (p99 latency at a fixed request rate) before touching anything.
a number to beatfixed load, fixed metric