---
# === IDENTITY ===
id: software/debugging/redis-memory-issues/2026
canonical_question: "How do I diagnose and fix Redis memory issues?"
aliases:
  - "Redis out of memory"
  - "Redis OOM command not allowed"
  - "Redis high memory usage"
  - "Redis memory fragmentation"
  - "Redis used_memory vs maxmemory"
  - "Redis eviction policy"
  - "Redis MEMORY DOCTOR"
  - "Redis memory leak"
  - "Redis activedefrag"
  - "Redis client output buffer overflow"
entity_type: software_reference
domain: software > debugging > redis_memory_issues
region: global
jurisdiction: global
temporal_scope: 2020-2026

# === VERIFICATION ===
last_verified: 2026-02-23
confidence: 0.93
version: 1.0
first_published: 2026-02-23

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: stable
  last_breaking_change: "Redis 7.0 — active defrag improvements, MEMORY command enhancements"
  next_review: 2026-08-22
  change_sensitivity: low

# === CONSTRAINTS ===
constraints:
  - "MEMORY USAGE, MEMORY DOCTOR, and MEMORY STATS require Redis 4.0+ — older versions lack introspection commands"
  - "Active defragmentation requires Redis compiled with jemalloc (the default) — system jemalloc without JEMALLOC_FRAG_HINT will not defrag properly"
  - "Never set maxmemory to 0 (unlimited) in production — the OS OOM killer will terminate Redis without warning"
  - "CONFIG SET changes are ephemeral — always persist to redis.conf or use CONFIG REWRITE, otherwise changes are lost on restart"
  - "redis-cli --bigkeys and --memkeys perform a full SCAN — run on replicas or during low-traffic periods to avoid latency spikes"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "Redis is crashing or segfaulting, not running out of memory"
    use_instead: "Redis crash debugging — check core dumps, Redis logs, and redis-check-rdb for RDB corruption"
  - condition: "Problem is slow Redis queries, not memory pressure"
    use_instead: "Redis SLOWLOG analysis — use SLOWLOG GET to identify slow commands, not memory commands"
  - condition: "Redis Cluster rebalancing or slot migration issues"
    use_instead: "Redis Cluster administration — use redis-cli --cluster rebalance and CLUSTER INFO"

# === AGENT HINTS ===
inputs_needed:
  - key: "redis_version"
    question: "Which Redis version are you running (4.x, 5.x, 6.x, 7.x)?"
    type: choice
    options: ["4.x", "5.x", "6.x", "7.x"]
  - key: "deployment_type"
    question: "How is Redis deployed?"
    type: choice
    options: ["standalone", "sentinel", "cluster", "managed (AWS ElastiCache/GCP Memorystore/Azure Cache)"]
  - key: "symptom"
    question: "What is the primary symptom?"
    type: choice
    options: ["OOM errors (write rejected)", "high RSS but low used_memory", "gradual memory growth (leak)", "sudden memory spike", "evictions happening unexpectedly"]

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/software/debugging/redis-memory-issues/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-02-23)"

# === RELATED UNITS ===
related_kos:
  related_to:
    - id: "software/debugging/docker-oomkilled/2026"
      label: "Docker OOMKilled"
    - id: "software/debugging/nodejs-memory-leaks/2026"
      label: "Node.js Memory Leaks"
    - id: "software/debugging/python-memory-leaks/2026"
      label: "Python Memory Leaks"
  often_confused_with:
    - id: "software/debugging/postgresql-slow-queries/2026"
      label: "PostgreSQL Slow Queries — database performance issue, not in-memory store memory management"
    - id: "software/debugging/postgresql-connection-pool/2026"
      label: "PostgreSQL Connection Pool Exhaustion — connection issue, not memory pressure"

# === SOURCES (7 authoritative sources) ===
sources:
  - id: src1
    title: "Redis Documentation — Key Eviction"
    author: Redis Ltd.
    url: https://redis.io/docs/latest/develop/reference/eviction/
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
  - id: src2
    title: "Redis Documentation — Memory Optimization"
    author: Redis Ltd.
    url: https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
  - id: src3
    title: "Redis Documentation — MEMORY STATS Command"
    author: Redis Ltd.
    url: https://redis.io/docs/latest/commands/memory-stats/
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
  - id: src4
    title: "Memory Management Best Practices — Google Cloud Memorystore"
    author: Google Cloud
    url: https://docs.cloud.google.com/memorystore/docs/redis/memory-management-best-practices
    type: official_docs
    published: 2024-06-01
    reliability: high
  - id: src5
    title: "Best Practices for Memory Management — Azure Cache for Redis"
    author: Microsoft
    url: https://learn.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-memory-management
    type: official_docs
    published: 2024-09-01
    reliability: high
  - id: src6
    title: "Top Redis Headaches for DevOps — Client Buffers"
    author: Redis Ltd.
    url: https://redis.io/blog/top-redis-headaches-for-devops-client-buffers/
    type: technical_blog
    published: 2023-03-01
    reliability: high
  - id: src7
    title: "Redis Documentation — Client Handling"
    author: Redis Ltd.
    url: https://redis.io/docs/latest/develop/reference/clients/
    type: official_docs
    published: 2024-01-01
    reliability: authoritative
---

# How Do I Diagnose and Fix Redis Memory Issues?

## TL;DR

- **Bottom line**: Redis memory issues stem from five root causes: hitting the `maxmemory` limit, memory fragmentation (high RSS vs low `used_memory`), large or forgotten keys, client output buffer bloat, and missing/wrong eviction policies. Diagnose with `INFO memory` and `MEMORY DOCTOR`; fix by setting appropriate `maxmemory-policy`, enabling `activedefrag`, and auditing keys with `--bigkeys`/`--memkeys`. [src1, src2]
- **Key tool/command**: `redis-cli INFO memory` — shows `used_memory`, `used_memory_rss`, `mem_fragmentation_ratio`, `maxmemory`, and `evicted_keys` in a single command. [src3]
- **Watch out for**: Setting `maxmemory` without an eviction policy (default is `noeviction`) — Redis rejects all writes with `OOM command not allowed when used memory > 'maxmemory'` instead of evicting old keys. [src1]
- **Works with**: Redis 4.0+ (for MEMORY commands and active defrag). Core `INFO memory` works on all versions. [src2, src3]

## Constraints
<!-- Agents: read this section before recommending any action from this unit.
     These are hard constraints that must not be violated. -->

- **MEMORY commands require Redis 4.0+**: `MEMORY USAGE`, `MEMORY DOCTOR`, `MEMORY STATS`, and `MEMORY MALLOC-STATS` were introduced in Redis 4.0. On older versions, use `INFO memory` and `DEBUG OBJECT`. [src3]
- **Active defragmentation requires jemalloc**: Redis must be compiled with its bundled jemalloc (the default). System jemalloc without `JEMALLOC_FRAG_HINT` will not perform defragmentation. Verify with `INFO memory` — `mem_allocator` should show `jemalloc-5.x`. [src2, src4]
- **Never run `redis-cli --bigkeys` on a primary during peak traffic**: It performs a full `SCAN` of the keyspace and can cause latency spikes. Run on a replica or during maintenance windows. [src2]
- **Do not set `maxmemory` to 0 in production**: A value of 0 means no limit. Redis will consume all available RAM until the OS OOM killer terminates the process without a clean shutdown, risking data loss. [src1, src4]
- **`CONFIG SET` is ephemeral**: Runtime config changes via `CONFIG SET maxmemory` or `CONFIG SET maxmemory-policy` are lost on restart. Always follow with `CONFIG REWRITE` or update `redis.conf` manually. [src1]

## Quick Reference

| # | Cause | Likelihood | Signature | Fix |
|---|---|---|---|---|
| 1 | `maxmemory` reached with `noeviction` policy | ~30% of cases | `OOM command not allowed when used memory > 'maxmemory'` | Set `maxmemory-policy allkeys-lru` (or appropriate policy) [src1] |
| 2 | Memory fragmentation (high RSS, low dataset) | ~20% of cases | `mem_fragmentation_ratio` > 1.5 in `INFO memory` | Enable `activedefrag yes`; or restart Redis to compact memory [src2, src4] |
| 3 | Large/forgotten keys consuming disproportionate memory | ~15% of cases | `redis-cli --bigkeys` shows keys with millions of elements | Delete or restructure oversized keys; set TTLs [src2] |
| 4 | Client output buffer overflow (slow consumers) | ~10% of cases | `client_recent_max_output_buffer` high in `INFO clients`; `CLIENT LIST` shows large `oll`/`omem` | Tune `client-output-buffer-limit`; fix slow subscriber clients [src6, src7] |
| 5 | Replica output buffer growth | ~8% of cases | `mem_clients_slaves` large in `MEMORY STATS`; replica `qbuf` in GB range | Fix replica lag; increase `client-output-buffer-limit replica` or fix network [src6] |
| 6 | No TTL on keys (unbounded growth) | ~7% of cases | `db0:keys=N,expires=0` — zero keys have expiration set | Audit and set TTLs; use `volatile-*` eviction policies [src1, src4] |
| 7 | RDB/AOF fork doubling RSS | ~5% of cases | RSS spikes to 2x during `BGSAVE` or `BGREWRITEAOF` | Reserve 50% memory headroom; or use `aof-use-rdb-preamble yes` [src2, src5] |
| 8 | Lua scripts holding references | ~3% of cases | `used_memory_scripts` high in `INFO memory` | Avoid storing large data in Lua global variables; use `redis.call` results directly [src3] |
| 9 | Wrong maxmemory value (too low for workload) | ~2% of cases | Frequent `evicted_keys` but low `mem_fragmentation_ratio` | Increase `maxmemory` to match workload requirements [src1] |

## Decision Tree

```
START — Redis memory issue detected
|
+-- Is Redis returning "OOM command not allowed"?
|   +-- YES: Check maxmemory and eviction policy
|   |   +-- maxmemory-policy = noeviction? -> Set allkeys-lru or allkeys-lfu [Cause #1]
|   |   +-- maxmemory too low? -> Increase maxmemory [Cause #9]
|   |   +-- Keys have no TTL? -> Set TTLs, switch to volatile-lru [Cause #6]
|   +-- NO: Continue below
|
+-- Is RSS much higher than used_memory (fragmentation ratio > 1.5)?
|   +-- YES -> Enable activedefrag; consider restart for severe cases [Cause #2]
|   +-- NO: Continue below
|
+-- Is used_memory growing steadily without stabilizing?
|   +-- YES: Run redis-cli --bigkeys and --memkeys
|   |   +-- Found oversized keys? -> Delete/restructure/TTL [Cause #3]
|   |   +-- No big keys but mem_clients_normal is high? -> Client buffer issue [Cause #4]
|   |   +-- mem_clients_slaves is high? -> Replica buffer issue [Cause #5]
|   +-- NO: Continue below
|
+-- Does RSS spike during BGSAVE/BGREWRITEAOF?
|   +-- YES -> Reserve memory headroom; tune AOF settings [Cause #7]
|   +-- NO -> Check used_memory_scripts and Lua usage [Cause #8]
```

## Step-by-Step Guide

### 1. Assess current memory state

The first step is always to get a complete picture of memory usage. [src3]

```bash
redis-cli INFO memory
```

Key fields to examine:
- `used_memory` — total bytes allocated by Redis (data + overhead)
- `used_memory_rss` — resident set size as reported by the OS
- `used_memory_peak` — historical peak memory usage
- `mem_fragmentation_ratio` — `used_memory_rss / used_memory` (healthy: 1.0-1.5)
- `maxmemory` — configured limit (0 = unlimited)
- `maxmemory_policy` — current eviction policy
- `mem_allocator` — should be `jemalloc-5.x` for defrag support

**Verify**: `redis-cli INFO memory | grep used_memory_human` → should show current usage in human-readable format.

### 2. Run MEMORY DOCTOR for automated diagnosis

Redis 4.0+ includes a built-in diagnostic advisor. [src3]

```bash
redis-cli MEMORY DOCTOR
```

This command analyzes memory stats and reports issues such as:
- High fragmentation ratio
- Peak memory significantly higher than current (suggests fragmentation)
- High ratio of RSS to dataset size

**Verify**: Output should be `Sam, I have no memory problems` if healthy, or a specific diagnostic message describing the issue.

### 3. Identify large keys consuming memory

Find keys using disproportionate amounts of memory. [src2]

```bash
# Find largest keys by element count (safe: uses SCAN internally)
redis-cli --bigkeys

# Find largest keys by memory usage (Redis 6.0+, uses MEMORY USAGE per key)
redis-cli --memkeys

# Check specific key memory usage
redis-cli MEMORY USAGE mykey
```

For production systems, add a sleep interval to reduce impact:
```bash
redis-cli --bigkeys -i 0.1
redis-cli --memkeys -i 0.1
```

**Verify**: Output shows the largest key per data type and summary statistics.

### 4. Check and fix eviction policy

If Redis hits `maxmemory` with `noeviction`, all writes fail. [src1]

```bash
# Check current policy
redis-cli CONFIG GET maxmemory-policy

# Set appropriate policy for cache workloads
redis-cli CONFIG SET maxmemory-policy allkeys-lru

# Persist the change
redis-cli CONFIG REWRITE
```

Eviction policy quick guide:
- `allkeys-lru` — best for general caching (evict least recently used from all keys)
- `allkeys-lfu` — best for frequency-based caching (Redis 4.0+, evict least frequently used)
- `volatile-lru` — only evict keys with TTL set (use when mixing cache + persistent data)
- `volatile-ttl` — evict keys closest to expiration
- `noeviction` — reject writes when full (use only for data that must not be lost)

**Verify**: `redis-cli CONFIG GET maxmemory-policy` → should show the new policy.

### 5. Enable active defragmentation for high fragmentation

If `mem_fragmentation_ratio` > 1.5, enable active defrag. [src2, src4]

```bash
# Enable active defragmentation
redis-cli CONFIG SET activedefrag yes

# Configure thresholds (optional — defaults are usually fine)
redis-cli CONFIG SET active-defrag-ignore-bytes 100mb
redis-cli CONFIG SET active-defrag-threshold-lower 10
redis-cli CONFIG SET active-defrag-threshold-upper 100
redis-cli CONFIG SET active-defrag-cycle-min 1
redis-cli CONFIG SET active-defrag-cycle-max 25

# Persist
redis-cli CONFIG REWRITE
```

**Verify**: `redis-cli INFO memory | grep mem_fragmentation_ratio` — should decrease over minutes to hours. Monitor with `INFO stats` field `active_defrag_running`.

### 6. Audit and fix client output buffers

Slow consumers (especially pub/sub subscribers) can cause massive buffer growth. [src6, src7]

```bash
# Check client buffer usage
redis-cli CLIENT LIST

# Look for clients with large omem (output buffer memory)
# Fields: id, addr, fd, name, omem (output buffer bytes), oll (output list length)

# Set buffer limits (hard limit, soft limit, soft time)
redis-cli CONFIG SET client-output-buffer-limit "normal 0 0 0"
redis-cli CONFIG SET client-output-buffer-limit "pubsub 32mb 8mb 60"
redis-cli CONFIG SET client-output-buffer-limit "replica 256mb 64mb 60"
```

**Verify**: `redis-cli INFO clients` — check `client_recent_max_output_buffer` has decreased after fixing slow consumers.

## Code Examples

### Python: Redis memory health check

> Full script: [python-redis-memory-health-check.py](scripts/python-redis-memory-health-check.py) (27 lines)

```python
# Input:  Redis connection URL
# Output: Memory health report dict with issues list
import redis
def check_redis_memory(url="redis://localhost:6379"):
    r = redis.Redis.from_url(url)
# ... (see full script)
```

### JavaScript (Node.js): Monitor memory with alerts

```javascript
// Input:  Redis connection options
// Output: Logs warnings when thresholds exceeded
import Redis from "ioredis"; // ioredis@5.x

async function monitorRedisMemory(redisUrl = "redis://localhost:6379") {
  const redis = new Redis(redisUrl);
  const info = await redis.info("memory");
  const parsed = Object.fromEntries(
    info.split("\r\n").filter(l => l.includes(":"))
      .map(l => l.split(":"))
  );
  const fragRatio = parseFloat(parsed.mem_fragmentation_ratio);
  const usedMem = parseInt(parsed.used_memory, 10);
  const maxMem = parseInt(parsed.maxmemory, 10);

  if (fragRatio > 1.5)
    console.warn(`[REDIS] High fragmentation: ${fragRatio}`);
  if (maxMem > 0 && usedMem / maxMem > 0.85)
    console.warn(`[REDIS] Memory at ${((usedMem/maxMem)*100).toFixed(1)}%`);
  if (parsed.maxmemory_policy === "noeviction" && maxMem > 0)
    console.warn("[REDIS] noeviction with maxmemory — writes will fail!");

  await redis.quit();
  return { fragRatio, usedMem, maxMem, policy: parsed.maxmemory_policy };
}
```

### Go: Programmatic memory diagnostics

> Full script: [go-programmatic-memory-diagnostics.go](scripts/go-programmatic-memory-diagnostics.go) (38 lines)

```go
// Input:  Redis address
// Output: MemoryReport struct with diagnostic fields
package main
import (
    "context"
# ... (see full script)
```

## Anti-Patterns

### Wrong: Setting maxmemory without an eviction policy

```bash
# BAD — noeviction is the default; Redis rejects ALL writes when full [src1]
redis-cli CONFIG SET maxmemory 2gb
# maxmemory-policy remains "noeviction"
# Result: "OOM command not allowed when used memory > 'maxmemory'"
```

### Correct: Always pair maxmemory with an eviction policy

```bash
# GOOD — set both together [src1]
redis-cli CONFIG SET maxmemory 2gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
redis-cli CONFIG REWRITE
```

### Wrong: Using KEYS * to find large keys in production

```bash
# BAD — KEYS blocks the entire server while scanning all keys [src2]
redis-cli KEYS "*session*"
# On a 10M key database, this blocks Redis for seconds
```

### Correct: Use SCAN-based tools for production key analysis

```bash
# GOOD — SCAN is non-blocking and incremental [src2]
redis-cli --bigkeys -i 0.1
redis-cli --memkeys -i 0.1
# Or use SCAN directly with a cursor
redis-cli SCAN 0 MATCH "*session*" COUNT 100
```

### Wrong: Ignoring mem_fragmentation_ratio below 1.0

```bash
# BAD — ratio < 1.0 means Redis is swapping to disk [src4]
# INFO memory shows:
# used_memory: 8000000000
# used_memory_rss: 4000000000
# mem_fragmentation_ratio: 0.50
# Developer thinks: "Great, Redis is using less OS memory"
# Reality: Redis is actively swapping — performance is catastrophically degraded
```

### Correct: Treat fragmentation ratio < 1.0 as critical

```bash
# GOOD — check for swapping immediately [src4, src5]
redis-cli INFO memory | grep mem_fragmentation_ratio
# If < 1.0: Redis data is being swapped to disk
# Fix: increase available RAM or reduce maxmemory
# Verify no swap: cat /proc/$(pidof redis-server)/smaps | grep Swap
```

### Wrong: Running activedefrag on Redis compiled with system libc malloc

```bash
# BAD — activedefrag silently does nothing without jemalloc [src2, src4]
redis-cli CONFIG SET activedefrag yes
# No error, but fragmentation never decreases
# Because mem_allocator is "libc" not "jemalloc"
```

### Correct: Verify allocator before enabling defrag

```bash
# GOOD — check allocator first [src2]
redis-cli INFO memory | grep mem_allocator
# Expected: mem_allocator:jemalloc-5.3.0
# If not jemalloc: rebuild Redis from source or use official packages
redis-cli CONFIG SET activedefrag yes
```

## Common Pitfalls

- **Not setting TTLs on cache keys**: Without TTLs, the keyspace grows indefinitely. If using `volatile-*` eviction policies, keys without TTLs are never evicted, leading to OOM even with eviction enabled. Set TTLs on all cache data. [src1, src4]
- **Confusing `used_memory` with `used_memory_rss`**: `used_memory` is what Redis reports internally; `used_memory_rss` is what the OS allocates. The gap is fragmentation overhead. Monitoring only `used_memory` misses fragmentation-related OOM from the OS perspective. [src3, src5]
- **Forgetting about fork overhead**: `BGSAVE` and `BGREWRITEAOF` fork the Redis process. Due to copy-on-write, write-heavy workloads during fork can temporarily double RSS. Reserve at least 50% memory headroom, or use `aof-use-rdb-preamble yes`. [src2, src5]
- **Pub/Sub subscribers that fall behind**: Slow pub/sub consumers cause Redis to buffer all messages in the output buffer. A single slow subscriber can consume GB of RAM. Set `client-output-buffer-limit pubsub 32mb 8mb 60` to disconnect slow consumers. [src6, src7]
- **Using FLUSHALL to "fix" memory issues**: `FLUSHALL` deletes all data but does not return memory to the OS immediately due to allocator fragmentation. RSS remains high until defragmentation occurs or Redis restarts. [src2]
- **Storing large blobs in Redis**: Storing objects larger than 1MB (images, serialized datasets) in Redis causes fragmentation and uneven memory allocation. Use external storage (S3, filesystem) with Redis storing only references. [src2, src4]
- **Not monitoring evicted_keys**: A high `evicted_keys` counter in `INFO stats` means Redis is actively dropping data to stay under `maxmemory`. This causes cache misses and increased backend load. Alert on eviction rate, not just memory usage. [src1]

## Diagnostic Commands

> Full script: [diagnostic-commands.sh](scripts/diagnostic-commands.sh) (28 lines)

```bash
# === Memory overview ===
redis-cli INFO memory
# === Automated memory diagnosis (Redis 4.0+) ===
redis-cli MEMORY DOCTOR
# === Detailed memory statistics breakdown ===
# ... (see full script)
```

## Version History & Compatibility

| Feature | Available Since | Notes |
|---|---|---|
| `INFO memory` section | Redis 2.4+ | Core memory reporting — works on all modern versions [src3] |
| `maxmemory` + eviction policies | Redis 2.0+ | LRU, random, volatile, noeviction [src1] |
| `MEMORY USAGE <key>` | Redis 4.0 | Per-key memory introspection [src3] |
| `MEMORY DOCTOR` | Redis 4.0 | Automated memory diagnosis [src3] |
| `MEMORY STATS` | Redis 4.0 | Detailed memory breakdown by category [src3] |
| Active defragmentation (`activedefrag`) | Redis 4.0 | Requires jemalloc; improved significantly in 6.0 and 7.0 [src2, src4] |
| LFU eviction policies (`allkeys-lfu`, `volatile-lfu`) | Redis 4.0 | Frequency-based eviction alternative to LRU [src1] |
| `redis-cli --memkeys` | Redis 6.0 | Memory-based key scanning (uses `MEMORY USAGE` per key) [src2] |
| Multi-threaded I/O | Redis 6.0 | Reduces client buffer memory pressure on high-connection workloads [src7] |
| Active defrag improvements | Redis 7.0 | Better handling of large allocations, reduced CPU overhead [src2] |

## When to Use / When Not to Use

| Use When | Don't Use When | Use Instead |
|---|---|---|
| Redis returns `OOM command not allowed` errors | Redis is slow but not out of memory | `SLOWLOG GET` for query performance analysis |
| `mem_fragmentation_ratio` > 1.5 or < 1.0 | Memory usage is stable and within limits | Regular monitoring is sufficient |
| `evicted_keys` increasing but data should persist | Keys are being evicted as designed (cache use case) | Eviction is working correctly — no action needed |
| RSS grows continuously without stabilizing | RSS spikes only during BGSAVE/BGREWRITEAOF | Normal fork behavior — ensure headroom exists |
| Client output buffers consuming significant memory | Single slow query blocking Redis | `CLIENT KILL` the offending client or `SLOWLOG` analysis |

## Important Caveats

- **Managed Redis services (ElastiCache, Memorystore, Azure Cache) have different defaults**: Many managed services pre-configure `maxmemory-policy` to `volatile-lru` and reserve 10-25% of memory for overhead. Check your provider's documentation before changing settings, as some config parameters may be locked. [src4, src5]
- **`mem_fragmentation_ratio` is misleading immediately after restart**: Right after restart, RSS is minimal and the ratio may be very high (>5.0) or very low. Wait until memory usage stabilizes before diagnosing fragmentation. [src3]
- **Active defragmentation trades CPU for memory**: Enabling `activedefrag` uses 1-25% of CPU (configurable via `active-defrag-cycle-min/max`). On CPU-bound workloads, this may increase latency. Monitor with `INFO stats` field `active_defrag_running`. [src2, src4]
- **Transparent Huge Pages (THP) cause latency spikes and inflate RSS**: Linux THP causes copy-on-write during fork to copy 2MB pages instead of 4KB pages, dramatically increasing fork memory usage and latency. Disable with `echo never > /sys/kernel/mm/transparent_hugepage/enabled`. [src2, src5]
- **Redis Cluster splits maxmemory per node, not across the cluster**: Each node in a Redis Cluster has its own `maxmemory` limit. Total cluster memory is the sum of all node limits, but keys are sharded — uneven distribution can cause OOM on individual nodes while others have free memory. [src1]

## Related Units

- [Docker OOMKilled](/software/debugging/docker-oomkilled/2026)
- [Node.js Memory Leaks](/software/debugging/nodejs-memory-leaks/2026)
- [Python Memory Leaks](/software/debugging/python-memory-leaks/2026)