Linux Performance Tuning — Silent Swap from vm.swappiness

A default Linux installation is deliberately conservative. The kernel ships with settings tuned for broad compatibility — a database server, a gaming rig, a Raspberry Pi, and a 64-core cloud VM will all boot with roughly the same baseline config. That's great for getting started, but catastrophic for production at scale. A misconfigured TCP buffer kills throughput on a 10 Gbps link. The wrong I/O scheduler on NVMe storage adds 40% latency. A forgotten vm.swappiness setting causes a Redis node to start swapping under load, tanking p99 response times from 2ms to 4 seconds. These aren't theoretical problems — they're war stories from real oncall rotations.

Performance tuning solves the gap between 'it works' and 'it works under pressure'. The Linux kernel exposes hundreds of tuneable knobs through /proc, /sys, and sysctl. Understanding which knobs affect which subsystem — and crucially, WHY they exist — lets you make surgical changes instead of cargo-culting settings from a Stack Overflow post that was written for a 2012 spinning-disk server.

By the end of this article you'll understand how the kernel scheduler, virtual memory subsystem, I/O stack, and network stack interact with each other. You'll be able to profile a live system, identify the bottleneck, apply the right tuning, and verify the improvement with hard numbers — all without rebooting. You'll also know which changes to make permanent and which to test ephemerally first.

What is Linux System Performance Tuning?

Linux system performance tuning is the practice of modifying kernel parameters via /proc, /sys, and sysctl to adjust the OS's behaviour for a specific workload. Default settings target broad compatibility, not peak performance. Tuning is not a one-time event — it's an iterative cycle of measurement, change, verification.

The kernel exposes these knobs because there's no single 'best' config. A web server that handles short-lived connections needs different TCP buffers than a file server streaming large files. A real-time analytics database needs different memory pressure settings than a batch processing job.

The goal is to close the gap between 'works' and 'works under production load'. That means measuring latency, throughput, and resource utilisation before and after each change.

Kernel Scheduler Tuning — CPU Affinity, CFS & NUMA

The Completely Fair Scheduler (CFS) allocates CPU time proportionally among processes. Its main tuning knobs control preemption aggressiveness, group scheduling, and NUMA balancing.

Also use taskset to pin processes to specific cores and numactl to bind memory to local NUMA node.

#!/bin/bash
# TheCodeForge — Linux scheduler tuning for an API server
# Pins Nginx workers to cores 0-15 (physical CPUs) on a dual-socket NUMA system

export WORKER_PIDS=$(pgrep -f 'nginx: worker')

for pid in $WORKER_PIDS; do
    # Pin to first socket cores only (avoid cross-socket memory access)
    taskset -pc 0-15 $pid
done

# Sysctl tweaks for lower latency
sysctl -w kernel.sched_min_granularity_ns=1000000   # 1ms vs default 3ms
sysctl -w kernel.sched_wakeup_granularity_ns=2000000  # 2ms vs default 4ms
sysctl -w kernel.sched_migration_cost_ns=5000000    # 5ms → fewer migrations
sysctl -w kernel.numa_balancing=0                    # Disable NUMA balancing

Memory Management Tuning — vm.swappiness, dirty pages & huge pages

The virtual memory subsystem decides how aggressively to swap anonymous pages versus reclaim page cache. The key parameters:

• vm.swappiness: 0–100. Default 60 encourages swapping even with free memory. Set to 1 for latency-sensitive apps. 0 means no swapping until absolutely necessary (but kernel still swaps).
• vm.dirty_ratio / vm.dirty_background_ratio: When writeback starts. Default 20% dirty background, 50% dirty synchronous. On write-heavy systems, this can cause latency spikes when the kernel blocks writes. Lower to 5%/10% for transaction logs.
• vm.vfs_cache_pressure: Controls tendency to reclaim inode/dentry cache. Default 100. Lower to 50 on file servers to keep metadata in memory.
• vm.min_free_kbytes: Reserve memory to avoid direct reclaim under load. Set to 1% of RAM.

Huge pages (2MB vs 4KB) reduce TLB misses. For apps with large memory footprints (databases, JVMs), enable transparent huge pages (THP) or use explicit hugetlbfs. THP can cause allocation stalls – often better to disable it and pre-allocate huge pages.

#!/bin/bash
# TheCodeForge — Memory tuning for a MySQL database server
# Aim: reduce swap, control dirty writeback, and use huge pages

# Swap tuning
sysctl -w vm.swappiness=1
sysctl -w vm.min_free_kbytes=$(( $(grep MemTotal /proc/meminfo | awk '{print $2}') / 100 ))

# Dirty page tuning for transaction logs
sysctl -w vm.dirty_background_ratio=5
sysctl -w vm.dirty_ratio=10

# Reduce inode cache pressure
sysctl -w vm.vfs_cache_pressure=50

# Disable transparent huge pages (THP) to avoid stalls, use explicit huge pages instead
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Pre-allocate 1024 huge pages for MySQL buffer pool
sysctl -w vm.nr_hugepages=1024

# Verify
grep -i huge /proc/meminfo | head -4

I/O Subsystem Tuning — Scheduler, Queue Depth & Block Layer

The Linux block layer sits between file systems and hardware. Its main tunable is the I/O scheduler, which queues and reorders requests. On modern NVMe SSDs, the default (usually BFQ or CFQ) adds overhead. Switch to none (no reordering) or mq-deadline (minimise latency).

Also tune filesystem mount options: noatime, nobarrier for ext4, or use XFS with larger allocation groups.

#!/bin/bash
# TheCodeForge — I/O tuning for an NVMe-based database
DEV=/dev/nvme0n1

# Set scheduler to none (noop) for NVMe
echo none > /sys/block/nvme0n1/queue/scheduler

# Increase queue depth for multiple concurrent I/O
echo 1024 > /sys/block/nvme0n1/queue/nr_requests

# Reduce read-ahead since database does random I/O
echo 128 > /sys/block/nvme0n1/queue/read_ahead_kb

# Mount with noatime to reduce metadata writes
mount -o remount,noatime /data

# For ext4, disable barriers (safe on NVMe with power loss protection)
mount -o remount,noatime,nobarrier /data

# Check new settings
cat /sys/block/nvme0n1/queue/scheduler
cat /sys/block/nvme0n1/queue/nr_requests

Network Stack Tuning — TCP Buffers, Congestion Control & Ring Buffers

The network stack's biggest bottleneck is often TCP buffer sizing and interrupt processing. For high-speed links (>1 Gbps), default socket buffers are too small, causing underutilisation.

#!/bin/bash
# TheCodeForge — Network tuning for a 10Gbps web server

# Socket buffer maxima for 10G
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216

# TCP auto-tuning ranges
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'

# Use BBR congestion control (requires kernel 4.9+)
sysctl -w net.ipv4.tcp_congestion_control=bbr

# Increase backlog for bursty traffic
sysctl -w net.core.netdev_max_backlog=5000

# Enable RPS (Receive Packet Steering) on all cores for eth0
# For a 4-core machine: bitmap 0x0f (cores 0-3)
echo 'f' > /sys/class/net/eth0/queues/rx-0/rps_cpus

# Verify
sysctl net.ipv4.tcp_congestion_control
cat /sys/class/net/eth0/queues/rx-0/rps_cpus

Putting It All Together — A Repeatable Tuning Workflow

Follow this sequence to avoid chaos:

1. Baseline measurement: Collect latency, throughput, CPU, memory, I/O, and network metrics for at least 24 hours under typical load. Use tools like sar, sysstat, perf, and netdata.
2. Identify bottleneck: Use the USE method (Utilization, Saturation, Errors) – e.g., CPU util > 90%? I/O queue length growing? Network drops?
3. Hypothesis and change: Pick ONE parameter. Change it. Document why and expected effect.
4. Measure again: Same period and load type. Compare before/after.
5. Accept or rollback: If improvement >5% in the target metric, keep. If not, rollback and try different hypothesis.
6. Make persistent: Only after validation, add to /etc/sysctl.d/ or tuned profiles.

Treat every parameter change as an experiment. Use tools like 'tuned' to apply preset profiles for common workloads (latency-performance, throughput-performance).