Interactive Troubleshooter

Published: Sep 6, 2026

Redis Server Crashing: Memory and Persistence Fix

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

An interactive root-cause diagnostic tree to resolve Redis server crashes, Out of Memory (OOM) killer terminations, and persistence failures. Diagnose maxmemory eviction policies, copy-on-write fork allocation stalls, Transparent Huge Pages (THP), and AOF disk I/O bottlenecks.

Full Diagnostic Tree & Step-by-Step Overview

What specific symptom, log message, or process error accompanies your Redis server crash?

Process terminated by Linux OOM killer ('Out of memory: Kill process') or throws 'OOM command not allowed'.
Crash occurs during RDB snapshot (BGSAVE) or AOF rewrite (BGREWRITEAOF) with 'Can't save in background'.
Redis hangs, stalls, or crashes due to severe memory fragmentation, THP allocation delays, or swap thrashing.
Crash occurs during replica synchronization or client output buffer exhaustion ('Client buffer limit reached').

Which memory allocation condition or key eviction behavior describes your Redis instance state?

Linux kernel OOM killer terminates redis-server because vm.overcommit_memory is set to default (0).
Redis reaches maxmemory threshold and rejects writes with 'OOM command not allowed' under noeviction policy.
Unbounded memory growth caused by big keys, missing TTLs, or memory leaks without maxmemory limits.

Configure Linux Kernel Memory Overcommit (vm.overcommit_memory=1)

Solution:

Root Cause: Linux Kernel Memory Overcommit Heuristic Rejection

By default, Linux uses a heuristic memory overcommit algorithm (vm.overcommit_memory = 0). When Redis initiates background persistence tasks such as BGSAVE or BGREWRITEAOF, it executes a fork() system call to spawn a child process. Although Linux relies on Copy-on-Write (CoW), the kernel evaluates whether sufficient physical RAM is available to satisfy the child process's entire virtual address space. Under heuristic overcommit mode, if free RAM is less than total memory allocated by Redis, the fork() fails or the kernel Out-Of-Memory (OOM) killer selects the redis-server process for termination.

Step-by-Step Fix:

1Check Active Kernel Overcommit Setting:

Run sysctl in terminal:

bash
     sysctl vm.overcommit_memory

If the output is vm.overcommit_memory = 0 or 2, overcommit is restricting fork allocations.

2Enable Memory Overcommit Live:

Apply memory overcommit mode 1 (always overcommit) immediately:

bash
     sudo sysctl vm.overcommit_memory=1

3Persist Overcommit Configuration Across Reboots:

Edit /etc/sysctl.conf or add a drop-in file /etc/sysctl.d/99-redis.conf:

text
     vm.overcommit_memory = 1

Reload configuration:

bash
     sudo sysctl -p /etc/sysctl.d/99-redis.conf

Configure maxmemory Thresholds and Enforce Automatic Key Eviction

Solution:

Root Cause: Unbound Memory Growth Under noeviction Policy

When Redis is deployed without an explicit maxmemory setting on a 64-bit system, it will consume all available host RAM until the operating system forces an OOM termination. Conversely, if maxmemory is defined but maxmemory-policy remains set to the default noeviction, Redis rejects any write command that allocates additional memory (returning OOM command not allowed when used memory > 'maxmemory'), stalling write-heavy applications.

Step-by-Step Fix:

1Inspect Current Memory and Eviction Settings:

Open redis-cli and run:

text
     CONFIG GET maxmemory
     CONFIG GET maxmemory-policy

2Set Safe maxmemory Boundaries:

Leave a 25-30% RAM buffer for system processes, Redis overhead, and Copy-on-Write fork memory. For example, on an 8GB host, set maxmemory to 6gb:

text
     CONFIG SET maxmemory 6gb

3Configure Eviction Policy:

Set an automatic eviction policy based on your workload pattern:

For cache workloads: CONFIG SET maxmemory-policy allkeys-lru (or allkeys-lfu).

For mixed key-value stores with TTLs: CONFIG SET maxmemory-policy volatile-lru.

4Update Redis Configuration File:

Edit /etc/redis/redis.conf to persist changes:

text
     maxmemory 6gb
     maxmemory-policy allkeys-lru

Review the Redis Official Configuration Documentation for complete eviction policy parameters.

Audit Big Keys, Missing Expirations, and Lazy Asynchronous Deletion

Solution:

Root Cause: Unbounded Memory Bloat from Large Data Structures and Missing TTLs

Storing oversized Data Structures (such as Hashes, Lists, or Sets with millions of elements) causes uneven memory distribution and severe latency spikes during deletion. When application code omits Expirations (TTL) on temporary or session keys, memory accumulates indefinitely. Furthermore, executing synchronous DEL operations on large keys blocks the single-threaded Redis event loop, triggering health-check failures and sentinel node failovers.

Step-by-Step Fix:

1Identify Memory-Intensive Keys via CLI Scanning:

Run the Redis big keys scanner without blocking the instance:

bash
     redis-cli --bigkeys

For fine-grained memory inspection on specific keys, run:

text
     MEMORY USAGE key:name

2Enable Asynchronous Non-Blocking Deletions:

Use UNLINK instead of DEL in application code to delete keys in a background thread.

Enable automatic lazy freeing in /etc/redis/redis.conf:

text
     lazyfree-lazy-eviction yes
     lazyfree-lazy-expire yes
     lazyfree-lazy-server-del yes

3Enforce Expiration Patterns:

Audit application code to ensure write commands specify TTL parameters (e.g., SET key value EX 3600).

Which background persistence mechanism or disk error accompanies the snapshot crash?

Copy-on-Write (CoW) memory spikes during BGSAVE or BGREWRITEAOF exceed total host RAM.
Disk space saturation or incorrect file permissions on RDB/AOF working directory ('dir').
Append-Only File (AOF) write delays block main thread due to fsync I/O saturation.

Mitigate Copy-on-Write Memory Spikes During BGSAVE and AOF Rewrites

Solution:

Root Cause: Copy-on-Write (CoW) Memory Doubling During Child Process Fork

When Redis executes BGSAVE or BGREWRITEAOF, the parent process forks a child worker that inherits the memory page table. When write commands arrive during snapshot generation, Linux kernel Copy-on-Write (CoW) duplicates the modified memory pages. In write-heavy workloads, this page duplication can temporarily double memory usage, causing physical RAM exhaustion and triggering the kernel OOM killer.

Step-by-Step Fix:

1Audit Memory Copy-on-Write Overhead in Redis Logs:

Check /var/log/redis/redis-server.log for RDB/AOF completion metrics:

RDB: X MB of memory used by copy-on-write

2Reserve Headroom for Persistence Spikes:

Reduce maxmemory in /etc/redis/redis.conf so total instance RAM usage does not exceed 65-70% of physical system memory.

3Tune AOF Rewrite Triggers:

Increase auto-aof-rewrite-percentage to prevent frequent automatic rewrites under continuous write loads:

text
     auto-aof-rewrite-percentage 100
     auto-aof-rewrite-min-size 64mb

Resolve Persistence Directory Permissions and Disk Space Saturation

Solution:

Root Cause: Storage Space Depletion or File System Access Denials

When Redis attempts to flush snapshots (dump.rdb) or append logs (appendonly.aof) to disk, it writes to a temporary file before renaming it. If the target partition reaches 100% capacity or the redis service user lacks write permissions on the directory path specified in dir, the snapshot fails. Redis defaults to stop-writes-on-bgsave-error yes, which blocks incoming write operations to prevent data inconsistency.

Step-by-Step Fix:

1Check Working Directory Disk Capacity:

Retrieve configured path in redis-cli:

text
     CONFIG GET dir

Check available mount point storage in terminal:

bash
     df -h /var/lib/redis

2Verify File System Ownership and Permissions:

Ensure the redis user owns the working directory and files:

bash
     sudo chown -R redis:redis /var/lib/redis
     sudo chmod 755 /var/lib/redis

3Clear BGSAVE Failure Lock:

Once storage or permissions are restored, clear the write block live:

text
     CONFIG SET stop-writes-on-bgsave-error no

Configure Non-Blocking AOF Append Synchronization (no-appendfsync-on-rewrite)

Solution:

Root Cause: Main Thread Blocking on AOF fsync Disk I/O Saturation

When appendfsync everysec is active, a background thread flushes AOF buffers to disk every second. However, if a background BGSAVE or BGREWRITEAOF generates heavy disk I/O, the kernel delays the fsync() write. If the delay exceeds 2 seconds, the main Redis thread blocks itself to prevent AOF buffer corruption, hanging the server and dropping incoming client connections.

Step-by-Step Fix:

1Check Redis Logs for AOF Latency Warnings:

Search /var/log/redis/redis-server.log for warnings:

Asynchronous AOF fsync is taking too long (steady state). Writing block to disk...

2Enable no-appendfsync-on-rewrite in Configuration:

Edit /etc/redis/redis.conf to disable fsync() calls while child rewrite processes are actively running:

text
     no-appendfsync-on-rewrite yes

3Migrate AOF Storage to High-IOPS SSD/NVMe Drives:

Ensure Redis persistence files reside on dedicated storage with sufficient IOPS capacity to handle parallel write operations.

Which system-level OS performance anomaly or memory allocator issue is affecting Redis?

Transparent Huge Pages (THP) active in Linux kernel, causing latency spikes and memory duplication.
High memory fragmentation ratio (mem_fragmentation_ratio > 1.5) under heavy key allocation/deletion cycles.
Kernel swapping active due to aggressive vm.swappiness settings causing event loop stalls.

Disable Linux Transparent Huge Pages (THP)

Solution:

Root Cause: Transparent Huge Pages (THP) Memory Allocation Overhead

Linux Transparent Huge Pages (THP) increases default memory page size from 4KB to 2MB. When Redis forks a child process for persistence, Copy-on-Write operates on 2MB allocation chunks instead of 4KB pages. If a write command modifies a single byte, the kernel duplicates an entire 2MB page, drastically inflating RAM usage during snapshots and introducing major latency spikes that crash sensitive application connections.

Step-by-Step Fix:

1Check Active THP Status:

Run command in terminal:

bash
     cat /sys/kernel/mm/transparent_hugepage/enabled

If [always] or [madvise] is selected in brackets, THP is active.

2Disable THP Live in Runtime Kernel:

Execute commands as root:

bash
     echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
     echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag

3Create Systemd Startup Service to Ensure Permanent Fix:

Create /etc/systemd/system/disable-thp.service:

text
     [Unit]
     Description=Disable Transparent Huge Pages (THP)
     DefaultDependencies=no
     After=sysinit.target local-fs.target
     Before=mongod.service redis-server.service

     [Service]
     Type=oneshot
     ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'

     [Install]
     WantedBy=basic.target

Enable and run service:

bash
     sudo systemctl daemon-reload
     sudo systemctl enable --now disable-thp.service

Enable Jemalloc Active Defragmentation and Reclaim Unused Allocations

Solution:

Root Cause: Memory Fragmentation in Jemalloc Allocator

When Redis frequently creates, modifies, and deletes dynamic keys, the underlying memory allocator (Jemalloc) can hold allocated memory pages that contain empty gaps. The mem_fragmentation_ratio (used_memory_rss / used_memory) rises above 1.5, meaning physical memory RSS is 50% higher than actual data payload sizes. This ghost allocation can push total host memory into OOM territory.

Step-by-Step Fix:

1Inspect Memory Fragmentation Metrics in redis-cli:

Query memory metrics:

text
     INFO memory

Check mem_fragmentation_ratio and allocator_frag_bytes.

2Enable Active Defragmentation Live:

Activate dynamic defragmentation in redis-cli:

text
     CONFIG SET activedefrag yes

3Configure Defragmentation Thresholds in /etc/redis/redis.conf:

Set automated parameters so defragmentation runs when fragmentation exceeds 100MB and 15% ratio:

text
     activedefrag yes
     active-defrag-ignore-bytes 100mb
     active-defrag-threshold-lower 10
     active-defrag-threshold-upper 30
     active-defrag-cycle-min 5
     active-defrag-cycle-max 50

Configure Linux Kernel Swappiness (vm.swappiness=1)

Solution:

Root Cause: Kernel Memory Swappiness and Disk I/O Thrashing

Linux kernel defaults to vm.swappiness = 60, aggressively swapping idle memory pages out to disk swap space. Because Redis relies on fast in-memory pointer access across its data structures, swapping Redis memory pages to disk causes extreme thread stalls, dropping ping health checks and causing Sentinel clusters to register node crashes.

Step-by-Step Fix:

1Inspect Active Swappiness Setting:

Run in terminal:

bash
     sysctl vm.swappiness

2Set Minimal Swappiness Live:

Reduce swappiness to 1 (instructing kernel to avoid swap unless completely out of RAM):

bash
     sudo sysctl vm.swappiness=1

3Persist Swappiness Value Across Reboots:

Add to /etc/sysctl.conf:

text
     vm.swappiness = 1

Reload sysctl:

bash
     sudo sysctl -p

Which replication buffer or client socket restriction triggers the failure?

Replica client output buffer limit reached during full replication synchronization.
Pub/Sub client or normal client output buffer exhaustion under slow consumer load.
Lua script execution timeout or infinite recursion triggering server process lockup.

Tune Replication Backlog and Replica Client Output Buffer Limits

Solution:

Root Cause: Replication Output Buffer Disconnection Loop

During primary-to-replica full synchronization (PSYNC), the primary node buffers all incoming write commands to send to the replica once the initial RDB transfer finishes. If the replication rate is slow or write volume is high, the buffer exceeds client-output-buffer-limit replica. Redis forcibly disconnects the replica, aborting the transfer and causing a continuous re-synchronization crash loop.

Step-by-Step Fix:

1Expand Replication Output Buffer Limits in /etc/redis/redis.conf:

Increase hard limit, soft limit, and soft limit duration for replica clients:

text
     client-output-buffer-limit replica 512mb 128mb 60

2Increase Replication Backlog Size:

Expand the circular replication buffer (repl-backlog-size) so short network disconnects can recover without full RDB resynchronization:

text
     repl-backlog-size 256mb

3Apply Buffer Settings Live:

Update live primary instance without restart:

text
     CONFIG SET client-output-buffer-limit "replica 536870912 134217728 60"
     CONFIG SET repl-backlog-size 268435456

Tune Normal and Pub/Sub Client Output Buffer Limits

Solution:

Root Cause: Unbounded Client Output Buffer Saturation by Slow Consumers

When Redis pub/sub subscribers or standard clients execute massive data queries (such as KEYS * or large HGETALL calls) but read data slowly off the TCP socket, Redis buffers pending outgoing responses in RAM. If subscriber buffers grow unchecked, memory usage balloons rapidly, causing out-of-memory crashes or socket terminations.

Step-by-Step Fix:

1Adjust Client Output Buffer Limits in /etc/redis/redis.conf:

Configure limits for Pub/Sub and normal client connections:

text
     client-output-buffer-limit normal 0 0 0
     client-output-buffer-limit pubsub 32mb 8mb 60

2Enforce Client Timeout Limits:

Disconnect idle client sockets after a period of inactivity (e.g., 300 seconds):

text
     timeout 300

3Prevent Heavy Blocking Commands in Application Code:

Replace KEYS * operations with iterative SCAN queries in application logic.

Set Lua Script Execution Limits and Asynchronous Termination

Solution:

Root Cause: Unbounded Lua Script Execution and Thread Lockup

Because Redis executes Lua scripts atomically on its primary event loop thread, an infinite loop or heavy computational cycle inside a Lua script blocks all other incoming client commands. If the script execution time exceeds lua-time-limit, Redis accepts administrative commands but rejects standard data operations with a busy server error.

Step-by-Step Fix:

1Configure Max Lua Execution Time in /etc/redis/redis.conf:

Set a maximum execution threshold in milliseconds (default 5000ms):

text
     lua-time-limit 5000

2Terminate Unresponsive Lua Scripts via CLI:

Open redis-cli and attempt to interrupt the running script:

text
     SCRIPT KILL

If the script has already executed write commands, SCRIPT KILL will fail to maintain atomicity. Execute SHUTDOWN NOSAVE to stop the instance safely without persisting corrupted state.

Related Diagnostic Guides

Windows Update Error 0x80070002 Missing Files Diagnostic Guide

System Restore Failed 0x80070005 Antivirus Conflict Tree

Windows Photo Viewer Not Showing Thumbnails: Codec Diagnostic

Safe Mode Password Not Working With Microsoft Account Fix

Clipboard History Not Working Windows 11: Sync Service Tree

Subscribe to StepDiag

Embed Guide on Your Website