Your application starts logging MISCONF Valkey is configured to save RDB snapshots, but it's currently unable to persist to disk and every write fails. Or p99 latency jumps each time a snapshot starts, and memory climbs until the OOM killer steps in. Both come from one mechanism: BGSAVE, save points, AOF rewrites, and replica full syncs all call fork(), and a large dataset makes the fork slow and its copy-on-write memory expensive. This guide covers Valkey 9.1.3 (26 October 2026): reading the error and INFO fields, the Linux settings that break the fork, memory headroom, and scheduling. It ends with forkless snapshots in the Valkey 9.2 release candidates and a staging trial plan.
MISCONFmeans the last background save failed while save points are configured andstop-writes-on-bgsave-errorisyes(the default). Writes come back on their own after the next successful save.- Read the log first:
Can't save in background: fork: Cannot allocate memorypoints tovm.overcommit_memory;terminated by signal 9points to the OOM killer. - Set
vm.overcommit_memory = 1, keep transparent huge pages offalways, and size memory for the copy-on-write peak you measure inrdb_last_cow_size. - Track
latest_fork_usec(INFO stats): it is the main-thread pause each fork causes. - Valkey 9.2 adds opt-in forkless BGSAVE and forkless full sync, but only in release candidates (9.2.0-rc2 as of November 2026). The policy config was renamed between rc1 and rc2. Trial it in staging only.
Scope and review date: November 2026. This post covers self-managed Valkey 9.1.3 and 9.0.7 on Linux, with notes on 8.1 and on the 9.2.0-rc2 release candidate. Defaults, INFO fields, log lines, and error strings were checked against the Valkey documentation, the release notes, and the 9.1.3 and 9.2.0-rc2 source on 10 November 2026. The commands were not run in a lab, so rehearse them on a staging host first.
What does the MISCONF error mean, and why did writes stop?
Valkey rejects write commands with MISCONF when three things are true: at least one save point is configured, stop-writes-on-bgsave-error is yes, and the last background save failed. Reads keep working, but PING returns the same error, so a health check built on PING marks the node as down. The server built-in save points are 3600 1 300 100 60 10000, so an instance with no save line in its config still snapshots.
The error clears by itself. In the 9.1.3 source, any successful background save sets the status back to ok, and automatic saves retry 5 seconds after a failure (CONFIG_BGSAVE_RETRY_DELAY). If the cause is still there, every retry fails the same way.
valkey-cli CONFIG GET save
valkey-cli CONFIG GET stop-writes-on-bgsave-error
valkey-cli INFO persistence | grep -E 'rdb_last_bgsave_status|rdb_changes_since_last_save|rdb_last_save_time'Interpretation: rdb_last_bgsave_status:err with a non-empty save value confirms the MISCONF cause. rdb_changes_since_last_save counts writes that exist only in memory. rdb_last_save_time is a Unix timestamp; convert it to see how old your newest good snapshot is.
A failed BGSAVE seen from valkey-cli
Illustrative output: field names match Valkey 9.1.3, the numbers are invented
Read it in this order: the save failed, the last good save copied about 9 GB (rdb_last_cow_size), and the last fork paused the main thread for 0.6 s. The error text is from the 9.1.3 source.
CONFIG SET stop-writes-on-bgsave-error no brings writes back at once, but the instance then runs with no new snapshot, and a restart loses everything since rdb_last_save_time. Use it only as an emergency step, with an alert on rdb_last_bgsave_status.
What does fork() cost a large Valkey instance?
The fork runs on the main thread, so every client waits while it happens. The kernel copies the parent's page table, which grows with memory. The Valkey latency guide works the example: a 24 GB instance with 4 kB pages needs a 48 MB page table, and the fork has to allocate and copy all of it. Older virtualized hosts can be far slower.
Everything that persists or resynchronizes forks: BGSAVE, save points, BGREWRITEAOF and automatic AOF rewrites, and replica full syncs. Diskless full sync (repl-diskless-sync yes, the default) still forks; per the replication guide, the background process streams the snapshot to the replica's socket instead of a file.
valkey-cli INFO stats | grep -E 'latest_fork_usec|total_forks'
valkey-cli CONFIG SET latency-monitor-threshold 100
valkey-cli LATENCY HISTORY fork
valkey-cli LATENCY DOCTORInterpretation: latest_fork_usec is the last fork's duration in microseconds. The latency monitor records the fork event only once latency-monitor-threshold is above 0 (the default is 0, off). LATENCY DOCTOR also reports a fork rate in GB per second of used memory; the 9.1.3 source calls under 10 "terrible", under 25 "poor", under 100 "good", and anything higher "excellent".
What happens during a fork-based BGSAVE
The pause is step 1; the memory growth is step 3, and it lasts until the child exits
Two costs, two fields: step 1 shows up as latest_fork_usec, and step 3 shows up as current_cow_size while the child runs and rdb_last_cow_size after it exits.
How much extra memory does copy-on-write need?
After the fork, parent and child share every memory page. When a client write changes a page in the parent, the kernel copies that page first, so the child keeps its point-in-time view. The Valkey administration guide says a write-heavy instance can use up to 2 times its normal memory during an RDB save or AOF rewrite, and that the extra is proportional to the pages modified during the save.
Valkey 8.1.0 reduced the copying by freeing strings during BGSAVE and AOF rewrite (#905 in the 8.1.0-rc1 release notes).
valkey-cli INFO persistence | grep -E 'cow|current_fork_perc|current_save_keys'
grep 'Fork CoW for RDB' /var/log/valkey/valkey-server.log | tail -5Interpretation: while a child runs, current_cow_size and current_cow_peak show the copied bytes and current_fork_perc shows progress. After it exits, rdb_last_cow_size (and aof_last_cow_size for rewrites) keep the final figure. The log line Fork CoW for RDB: current X MB, peak Y MB, average Z MB is written when the child finishes, so the log keeps a history of past peaks.
Size from measurement, not from the 2x rule. Run a save in your busiest write hour and take the peak. You need roughly used_memory_rss, plus that peak, plus replication and client output buffers, plus a fragmentation margin.
valkey-cli INFO memory | grep -E '^(used_memory_rss|maxmemory):'
grep -E '^(MemAvailable|CommitLimit|Committed_AS):' /proc/meminfoInterpretation: if the measured CoW peak is larger than MemAvailable, the next save during a write burst can fail or wake the OOM killer. CommitLimit and Committed_AS matter only in strict overcommit mode.
Which Linux settings make BGSAVE fail: overcommit and huge pages?
When the fork itself fails, Valkey logs Can't save in background: fork: Cannot allocate memory and marks the save as failed. The usual cause is the kernel's overcommit policy. The Linux overcommit documentation lists three modes: 0 (heuristic, the default) refuses "obvious overcommits", 1 always overcommits, and 2 refuses any commit above CommitLimit. A fork asks to commit as much address space as the parent holds, even though most of it is never copied.
The Valkey FAQ gives the example of a 3 GB dataset with 2 GB of free memory failing to fork, and recommends mode 1. Valkey's own startup check (also run by valkey-server --check-system) warns whenever the value is not 1.
sysctl vm.overcommit_memory
valkey-server --check-system
sudo sysctl -w vm.overcommit_memory=1Interpretation: the system check prints one line per check, such as [overcommit]...OK or WARNING: followed by the fix. On Linux, 9.1.3 runs slow-clocksource, xen-clocksource, overcommit, and THP, plus madvise-free-fork-bug on arm64. The sysctl -w change applies immediately but does not survive a reboot.
# /etc/sysctl.d/60-valkey.conf
vm.overcommit_memory = 1Interpretation: the drop-in file persists the setting; load it with sudo sysctl --system. On Kubernetes it is a node setting, not a pod setting.
Transparent huge pages (THP) make copy-on-write much worse: a write copies a whole huge page instead of a 4 kB page, and the latency guide warns that a few event loops on a busy instance can copy almost the whole process memory. Valkey ships disable-thp yes (immutable), which turns THP off for its own process when the kernel is set to always. The docs still say echo never; the 9.1.3 startup warning recommends madvise, and 9.2.0-rc1 changed LATENCY DOCTOR to match (#3947). Either works. Our Valkey latency incident runbook shows how to check AnonHugePages on a running process.
cat /sys/kernel/mm/transparent_hugepage/enabled
echo madvise | sudo tee /sys/kernel/mm/transparent_hugepage/enabledInterpretation: the active value is in brackets, for example always [madvise] never. If it reads [always] and you changed it, restart Valkey: pages already allocated as huge pages stay that way.
How do you keep the OOM killer away from the primary?
If the fork succeeds but copy-on-write uses up the host's memory, the kernel's OOM killer picks a process. If it picks the RDB child, Valkey logs Background saving terminated by signal 9, marks the save failed, and you get MISCONF. If it picks the primary, you lose the instance. By default Valkey leaves the choice to the kernel: oom-score-adj is no.
# valkey.conf (Valkey 9.1)
oom-score-adj relative
# primary, replica, background child (range -2000 to 2000; higher dies first)
oom-score-adj-values 0 200 800Interpretation: with relative, the values are added to the process's starting oom_score_adj and clamped to -1000 to 1000. The defaults make the kernel kill a forked child first, then a replica, then the primary. An unprivileged process can always raise its own score, so positive values work without root. Both settings accept CONFIG SET.
pid=$(valkey-cli INFO server | awk -F: '/^process_id/{print $2}' | tr -d '\r')
cat /proc/$pid/oom_score_adj
sudo dmesg -T | grep -i -E 'out of memory|killed process' | tail -5Interpretation: after the change, a primary that started at 0 reads 0, and a running RDB child reads 800. A Killed process line in the kernel log, at the time of a failed save, confirms the OOM killer rather than a fork refusal. Losing the child is better than losing the primary, but the fix is still headroom.
How do you diagnose and fix a failing BGSAVE?
The runbook below is written for an incident where writes are already failing. Each step narrows the cause before you change anything.
Failing BGSAVE runbook for Valkey 9.1
Seven steps; writes are rejected during steps 1 to 6
-
Confirm the save failed
Writes rejectedLook for
rdb_last_bgsave_status:errand noterdb_last_save_time, your newest good snapshot.valkey-cli INFO persistence \ | grep -E 'rdb_last_bgsave|rdb_last_save_time' -
Read the reason in the server log
Writes rejectedA fork error means overcommit or memory; an error or signal means the child failed later.
CONFIG GET logfilegives the path.grep -E "Can't save|Background saving" \ /var/log/valkey/valkey-server.log | tail -
Check the host settings
Writes rejectedEvery check should print OK. Overcommit and THP are the two that break forks.
valkey-server --check-system sysctl vm.overcommit_memory -
Look for an OOM kill
Writes rejectedMatch the time to the failed save. If the child was killed, the cause is copy-on-write headroom.
sudo dmesg -T | grep -i 'killed process' -
Check the disk
Writes rejectedA full or read-only disk fails the child with an error, not a signal.
valkey-cli CONFIG GET dir df -h /var/lib/valkey -
Fix the cause and save again
Writes resume on successSet overcommit, free memory, or free disk, then start a save by hand instead of waiting for a save point.
sudo sysctl -w vm.overcommit_memory=1 valkey-cli BGSAVE -
Confirm writes are back
The status returns to ok,
LASTSAVEmoves forward, and a test write succeeds. Then persist the fix in sysctl and valkey.conf.valkey-cli INFO persistence \ | grep rdb_last_bgsave_status valkey-cli LASTSAVE
Main risk: step 6 starts a fork on an instance that is short of memory. If you are unsure about headroom, take the snapshot from a replica first, so the primary is not the one at risk.
If a running save is eating the last of the host's memory, BGSAVE CANCEL (Valkey 8.1.0 and later, #757; the command page's history table does not list it yet) stops it and frees its copy-on-write pages. The status of the last completed save still decides whether MISCONF applies.
valkey-cli BGSAVE CANCEL # replies "Background saving cancelled"Interpretation: an error reply means nothing was running or scheduled.
How should you size and schedule persistence to avoid fork stalls?
Persist on replicas, carefully
A common pattern is save "" on the primary and snapshots on a replica, so the primary forks only for full syncs. The replication guide warns that a primary without persistence that restarts automatically comes back empty, and its replicas copy the empty dataset. Fail over instead of auto-restarting it.
There is a second trap on the replica side. In the 9.1.3 source, the MISCONF check also runs for writes arriving from the primary, and with replica-ignore-disk-write-errors no (the default) the replica panics with Replica was unable to write command to disk. So a failed save can crash a persisting replica. On a read-only replica MISCONF protects nothing, so consider this:
# valkey.conf on a replica that takes the snapshots
save 3600 1 300 100
stop-writes-on-bgsave-error no
oom-score-adj relative
# alert on rdb_last_bgsave_status:err for this replicaInterpretation: with the check off, a failed save shows up only in INFO, so the alert is mandatory. Test the failure path in staging, for example by filling the disk.
Schedule saves off the write peak
Save points fire when enough changes pile up, so on a busy primary they fire in the busy hour. If you can accept a longer recovery point, replace them with a timed BGSAVE in the quiet hour. With no save points, a failed save never raises MISCONF, so alert on rdb_last_bgsave_status and rdb_last_save_time. AOF rewrites also fork: the 9.1.3 defaults (auto-aof-rewrite-percentage 100, auto-aof-rewrite-min-size 64mb) rewrite whenever the AOF doubles.
# cron on the snapshot host, 03:15 daily; SCHEDULE waits for an AOF rewrite
15 3 * * * valkey-cli BGSAVE SCHEDULE
valkey-cli CONFIG SET save ""
valkey-cli CONFIG REWRITEInterpretation: BGSAVE SCHEDULE waits for a running AOF rewrite instead of failing, and CONFIG REWRITE keeps the empty save list across restarts. For full syncs, repl-diskless-sync-delay (5 seconds by default) lets replicas that reconnect together share one fork. A large enough repl-backlog-size lets a short disconnect resume without a full sync.
One change to plan for if you move to 9.2: active expiration now counts as a change for save points (#3118 in the 9.2.0-rc1 release notes), so a cache with many TTLs will hit its save points, and fork, more often.
What do forkless snapshots and forkless full sync change in Valkey 9.2?
Valkey 9.2 is a release candidate: the newest tag is 9.2.0-rc2 (4 November 2026). Nothing below is GA behavior. 9.2.0-rc1 added forkless RDB snapshots (#4460): a background thread inside the server writes the snapshot, so there is no child, no page table copy, and no copy-on-write. 9.2.0-rc2 extended this to disk and diskless replica full syncs (#4797). Two settings control it, per the 9.2.0-rc2 valkey.conf:
# Valkey 9.2.0-rc2 only. valkey.conf has no inline comments.
# Immutable (startup only); adds 4 bytes per key:
forkless-infrastructure-enabled yes
# require-fork (default) or prefer-forkless:
forkless-policy prefer-forklessInterpretation: the first setting only adds per-key metadata. The second accepts CONFIG SET, but prefer-forkless is refused unless the server started with the infrastructure enabled. In rc1 the policy was bgsave-default-method (fork or forkless); rc2 renamed it (#5261) with no alias, so an rc1 config file needs editing.
The snapshot must still be point-in-time, so writes pay instead of memory. Per the #4460 pull request, a write to a key being serialized blocks that client until the key is done; the rc2 source also saves an unvisited key first when a client writes it. A script that writes an undeclared key makes the main thread wait synchronously, with a logged warning.
Fork-based and forkless saves side by side
Switch modes to see what moves from memory to write latency
Fork-based (9.1, 9.2 default)
| Aspect | Fork-based |
|---|---|
| Who writes the snapshot | A child process created by fork() |
| Main-thread pause at start | Page table copy, seen in latest_fork_usec |
| Extra memory during the save | Copy-on-write pages, up to 2x on write-heavy loads |
| Writes during the save | Never wait for the save |
| Operations covered | BGSAVE, save points, full sync, AOF rewrite |
| Standing cost | None |
| Release status | GA in 9.1.3 and 9.0.7 |
Forkless (9.2 RC, prefer-forkless)
| Aspect | Forkless |
|---|---|
| Who writes the snapshot | A background thread in the server process |
| Main-thread pause at start | No fork; total_forks does not increase |
| Extra memory during the save | No copy-on-write |
| Writes during the save | A write to a key not yet saved, or being saved, waits for that key |
| Operations covered | BGSAVE, save points, disk and diskless full sync; AOF rewrite still forks |
| Standing cost | 4 bytes per key once the infrastructure is enabled |
| Release status | 9.2.0-rc2 release candidate |
The trade: forkless swaps a memory spike and one long pause for many short per-key waits. Measure write latency during a save, not only memory, before you decide it is better for your workload.
Forkless is a preference. The rc2 source falls back to a fork, logs why, and counts it in INFO stats (forkless_fallbacks_*) when a module lacks forkless support, a slot import is running, the replicas need an RDB older than version 81, the sync uses repl-compression, or a diskless sync's replica lacks the inband-repl capability. So replicas not running 9.2, replicas with repl-diskless-load swapdb, and dual-channel replication still get a forked sync. The rc2 aof.c has no forkless path, so AOF rewrites still fork.
valkey-cli INFO persistence | grep -E 'bgsave_type|forkless_estimated|current_fork_perc'
valkey-cli INFO stats | grep -E 'forkless_fallbacks|total_forks'Interpretation: the two bgsave_type fields read fork, forkless, or none, and forkless_estimated_seconds_remaining is -1 when idle. A non-zero fallback counter names the part of your topology that still forks.
9.2.0-rc2 alone fixes a corrupt forkless snapshot after an unreplicated SWAPDB (#5116), a stale snapshot overwriting a newer dump.rdb (#5121), two crashes (#5082, #5206), a dangling pointer that could corrupt the iteration (#4996), and MULTI/EXEC handling in forkless full sync (#5205).
How should you trial forkless saves on a 9.2 release candidate?
Treat this as a staging test that decides whether to adopt forkless at 9.2.0 GA. The key rule is rollback: 9.2.0-rc2 writes RDB version 81 for every save, fork-based or forkless, and 9.1.3 refuses anything above version 80 under the default rdb-version-check strict, logging Can't handle RDB format version 81. Keep a 9.1-written snapshot outside the data directory before the first 9.2 save.
# 1. Before upgrading staging: keep a 9.1 snapshot aside
valkey-cli BGSAVE && sleep 60 && valkey-cli INFO persistence | grep rdb_last_bgsave_status
cp /var/lib/valkey/dump.rdb /backup/dump-9.1-$(date +%F).rdb
# 2. Start 9.2.0-rc2 with forkless-infrastructure-enabled yes, then baseline with fork
valkey-cli CONFIG SET forkless-policy require-fork
valkey-cli BGSAVE
# 3. Same load, forkless
valkey-cli CONFIG SET forkless-policy prefer-forkless
valkey-cli BGSAVE
valkey-cli INFO persistence | grep rdb_last_bgsave_typeInterpretation: run steps 2 and 3 under the same replayed write load. For the fork run record latest_fork_usec, the CoW peak, and client p99; for the forkless run record save duration, blocked_clients (which now counts clients waiting on a key), and client p99. Replace the sleep with a poll on rdb_bgsave_in_progress.
valkey-check-rdb /var/lib/valkey/dump.rdb
valkey-cli DEBUG DIGEST # needs enable-debug-command; compare on a restored copyInterpretation: valkey-check-rdb must read the forkless file cleanly. For a stronger check, pause writes, save, restore on a second staging instance, and compare digests.
Then test what the release notes say was broken: SWAPDB, FLUSHALL, and SHUTDOWN during a save, a full sync under write load, once to a normal 9.2 replica and once to one with repl-diskless-load swapdb (which forces the fork fallback), and a failover mid-sync. Repeat the test on 9.2.0 GA, because names, defaults, and the per-key cost can still change.
Frequently asked questions
How do I fix the Valkey MISCONF error?
Find why the last background save failed, fix it, and run BGSAVE. Check rdb_last_bgsave_status in INFO persistence, then read the server log. A fork error with "Cannot allocate memory" usually means vm.overcommit_memory is not 1. A child terminated by signal 9 means the OOM killer. Writes resume as soon as a save succeeds. Setting stop-writes-on-bgsave-error to no is a short-term workaround only.
How much memory does Valkey need for BGSAVE?
The Valkey administration guide says a write-heavy instance can use up to twice its normal memory during an RDB save or AOF rewrite, because each page written during the save is copied. Measure your real figure: run a save at peak write load and read rdb_last_cow_size in INFO persistence, or the "Fork CoW for RDB" line in the log. Keep that much free beyond used_memory_rss.
What is latest_fork_usec in Valkey?
It is an INFO stats field that reports how long the most recent fork() took, in microseconds. The fork runs on the main thread, so clients wait for that time. It grows with memory because the kernel copies the page table. Track it over time, and enable the latency monitor to record fork events above your threshold.
Should transparent huge pages be set to never or madvise for Valkey?
Either works. What matters is that the kernel setting is not always. The Valkey docs still say never, while the 9.1.3 startup check and the 9.2 release candidate recommend madvise. Valkey also ships disable-thp yes, which turns THP off for its own process when the kernel is set to always. Restart Valkey after changing the kernel setting.
Is forkless BGSAVE available in Valkey 9.1?
No. Forkless snapshots and forkless full sync exist only in the Valkey 9.2 release candidates, with 9.2.0-rc2 the newest as of November 2026. They need forkless-infrastructure-enabled yes at startup and forkless-policy prefer-forkless. The policy setting was renamed between rc1 and rc2, so test them in staging and wait for 9.2.0 GA before production.
Key takeaways
- MISCONF means a failed background save with save points configured; the log line tells you whether the fork, the child, or the disk failed.
- Set
vm.overcommit_memory = 1, keep THP offalways, and runvalkey-server --check-systemon every host. - Size memory from your measured
rdb_last_cow_sizepeak, and setoom-score-adj relativeso the kernel kills the child before the primary. - If replicas take the snapshots, protect them from the replica panic path and never auto-restart a primary that has no persistence.
- Valkey 9.2 forkless saves trade copy-on-write memory for per-key write waits; they are release-candidate only, and a 9.2 RDB cannot be loaded by 9.1.
Tune Valkey persistence with JusDB
JusDB's Valkey performance tuning team can review your persistence settings, host kernel settings, and memory headroom against your measured fork and copy-on-write figures. We can also plan a staging trial of the 9.2 forkless options with a defined rollback point.
Bring your INFO output, your valkey.conf, and the server log from a failed save. Your team approves every production change.