The fork’s two settings: huge pages & overcommit.

Valkey runs command execution on a single thread, so it cannot pause the world to write a snapshot. Instead it forks a child process and lets the child do the slow work. For an append-only-file rewrite, the child reads a consistent point-in-time view of the keyspace and writes the compacted log while the parent keeps serving commands.

The fork would be ruinous if it copied the whole heap. It does not. Linux gives parent and child the same physical pages and marks them read-only; the pages stay shared until one side writes. That is copy-on-write (COW): a page is duplicated only at the moment a write touches it, and only that one page. A child that reads without writing — the rewrite child — copies almost nothing. The parent copies a page only when a live command modifies it during the rewrite window.

So the cost of a fork is not the size of the dataset. It is the rate of writes during the rewrite times the size of the unit the kernel copies per write. That unit is what the first setting controls; whether the fork is allowed to start at all is the second.

A normal memory page is 4 KB. Transparent huge pages (THP) is a kernel feature that hands out 2 MB pages instead, to cut page-table pressure on large-heap workloads. For an in-memory store under copy-on-write it is the wrong trade.

The source states the mechanism plainly: with THP enabled the kernel uses 2 MB pages instead of 4 KB, so when the parent modifies a single byte during a rewrite the kernel must copy the entire 2 MB page — a 500× amplification of the work a 4 KB copy would have done. The visible symptoms in the source are latency spikes of 10–100× during BGSAVE or BGREWRITEAOF, memory usage doubling temporarily during persistence, and client timeouts during background saves.

The fix is to disable it. Write never to the kernel’s THP knob:

Make it permanent under systemd so it survives a reboot, as a pre-start step on the service:

Valkey logs a warning at startup if THP is still enabled. That warning is not noise — it is the engine reporting that a single-byte write during a fork will cost a 2 MB page copy. Address it, never ignore it.

THP is a kernel setting, written under /sys. It is not a valkey.conf directive: the config file tunes the server, the kernel knob tunes the host the server forks on.

The second setting is about whether the fork is allowed, not how cheap it is. The fork() call can fail when the kernel sizes the child as if it needs as much memory as the parent.

The source describes the trap: when Valkey forks, the kernel pessimistically reserves enough memory for the child to hold a full copy of the parent. On a box with most of its RAM already used, the fork can fail even though copy-on-write means almost no real memory is needed — the child shares the parent’s pages, it does not duplicate them. A pessimistic reservation refuses a fork that would have been free.

The fix tells the kernel to trust copy-on-write:

Persist it in /etc/sysctl.conf:

Setting vm.overcommit_memory=1 makes the kernel always grant the allocation, trusting that copy-on-write means the child’s nominal claim is never realized. Like THP, this is a kernel setting applied with sysctl, not a line in valkey.conf.

The course’s worked engine is the Valkey that backs EchoMQ — the owned bus over the braced emq:{q}: keyspace, the store the codemojex game’s queue runs on. Its real config sits at infra/valkey/conf/valkey.conf, and two of its lines exist to keep the fork cheap and rare.

maxmemory 512mb is a loud guardrail, not a working ceiling: the live dataset is single-digit megabytes (round leaderboards, presence, in-flight stream entries), so 512 MB sits far above it, leaving — in the file’s own words — ~half the box for fork copy-on-write during an AOF rewrite. The headroom THP and overcommit make usable is the headroom this line budgets.

save "" disables RDB snapshotting, which leaves the AOF rewrite as the one fork source. The file’s comment is explicit — one fork source — so RDB does not compete for a second fork. With appendonly yes and a single fork source, the copy-on-write spike is paid once per rewrite, not split across two competing children.

The valkey.conf file carries no THP or overcommit line, and it must not. THP and overcommit are host kernel settings (/sys and sysctl); the config file tunes the server process. The two layers cooperate: the kernel makes the fork cheap and allowed; the config budgets the headroom and keeps a single fork source.

A fork is cheap because of copy-on-write, and copy-on-write is cheap because the copied unit is small and the fork is allowed. THP off keeps the unit at 4 KB; vm.overcommit_memory=1 keeps the fork from being refused; EchoMQ’s maxmemory 512mb and save "" reserve the headroom and hold to one fork source. The next dive keeps the other thread fast — the single command thread the fork must never stall: swappiness, defragmentation, and the I/O-thread budget that protect tail latency between rewrites.