Linux kernel tuning for Redis.

THP is the most critical setting. When enabled, it causes severe latency spikes during persistence operations. The engine uses fork() to create a child process for an AOF rewrite, and Linux uses copy-on-write to share memory between parent and child. With THP enabled, the kernel hands out 2 MB pages instead of 4 KB pages. When the parent modifies a single byte during the rewrite window, the kernel must copy the entire 2 MB page — the source records this as a 500x amplification of the copy.

The symptoms the source lists: latency spikes of 10–100x during a background save, memory usage doubling temporarily during persistence, and client timeouts while the save runs. THP is a kernel setting, not a server one — turn it off at the host:

The fork() system call can fail if the kernel thinks there is insufficient memory. When the server forks, the kernel may pessimistically assume the child needs as much memory as the parent. The source’s example: on a 32 GB instance with 30 GB used, the fork can fail even though copy-on-write means little real memory is actually needed.

Overcommit is a kernel sysctl. Set it so the kernel always allows the allocation request, trusting that copy-on-write keeps the real cost small:

Data in swap is a catastrophic failure mode. If any of the server’s memory pages are swapped to disk, access times go from nanoseconds to milliseconds — the source measures this as a 1,000,000x slowdown. A single swapped page can cause client timeouts.

Swappiness is a kernel sysctl. The source sets it to 1 — not 0, because 0 can cause OOM kills; 1 makes swapping extremely unlikely while still allowing the kernel to swap in a desperate situation:

Under high connection rates, default TCP settings cause connection failures. The listen queue for incoming connections defaults to 128. During traffic spikes, new connections are dropped before the server ever sees them. Two of these are kernel sysctls and one is a server setting, and they interact: the effective backlog is min(tcp-backlog, somaxconn). Raise both, then set the server-side backlog and the keepalive interval:

Each connection consumes a file descriptor. The source raises the limit for the service account so a burst of clients is accepted rather than refused. In the systemd service file:

The engine uses jemalloc, which is well-suited to its allocation pattern. The source names two behaviours to watch. After deleting a large amount of data, jemalloc retains memory to satisfy future allocations, so the process RSS reflects peak usage rather than the current dataset size. And fragmentation shows up in mem_fragmentation_ratio (read from INFO MEMORY):

• below 1.0 — the process is using swap (critical);
• 1.0–1.5 — normal;
• above 1.5 — significant fragmentation.

When fragmentation is high, active defragmentation relocates live objects so empty pages can be returned to the OS. It is a server setting:

The host sysctls are only half the posture. The other half is the server’s own config file — and EchoMQ’s is real, committed, and applied. The kernel knobs (THP, overcommit, swappiness, somaxconn) live in the host; the application-level knobs live in infra/valkey/conf/valkey.conf. That file never carries a sysctl — it carries the threads, lazy-free, persistence, eviction, and defrag posture that the sysctls leave room for.

The manuscript states the kernel half from the inside: an in-memory store needs the kernel tuned away from its defaults — transparent huge pages off, overcommit set, swappiness low, and the connection backlog and file-descriptor limits raised so a burst of clients is accepted rather than dropped (bcs.8.md, B8.2).

Each dive takes one cluster of the source’s settings, in the arc the fork → the command thread → durability: the two settings that keep a fork cheap and allowed, the ones that keep the single command thread fast, and the ones that keep work durable on a crash. Read them in order — the fork starts.