Redis client output buffer overflow: slow consumers and client-output-buffer-limit

Redis accepts commands faster than some clients can read the responses. When a client’s read loop stalls, Redis keeps writing into that client’s output buffer because there is no backpressure mechanism for normal clients. The buffer grows on the main heap, and that memory counts against maxmemory. Under the right conditions, a single slow consumer can push the server into eviction, OOM rejection, or a crash.

The default client-output-buffer-limit normal 0 0 0 means unlimited. No hard limit, no soft limit, no timeout. This is a footgun that ships with every Redis instance. Pub/Sub and replica clients get defaults, but normal clients, the vast majority of connections, get nothing.

This article covers diagnosis and remediation when client output buffers are consuming server memory, driving eviction, or approaching OOM.

What this means

Each connected client has an output buffer where Redis queues response data that the client has not yet read from the socket. The buffer lives on the main heap alongside dataset memory, the replication backlog, Lua memory, and all other allocations. Its size counts against maxmemory.

When a client reads slower than Redis writes, the output buffer accumulates. For normal clients with the default client-output-buffer-limit normal 0 0 0, there is no cap. The buffer grows until either the client catches up or the server runs out of memory.

The client-output-buffer-limit directive controls three client classes:

Each limit is three values: hard_limit soft_limit soft_seconds. Exceeding the hard limit disconnects the client immediately. Exceeding the soft limit continuously for soft_seconds also triggers disconnection. A value of 0 means unlimited for that threshold.

flowchart TD
    A["Slow consumer reads slower than Redis writes"] --> B["Output buffer accumulates on server heap"]
    B --> C{"client-output-buffer-limit set?"}
    C -->|"No / 0 0 0 for normal"| D["Buffer grows unbounded"]
    C -->|"Yes, limit configured"| E["Client disconnected when limit exceeded"]
    D --> F["Buffer memory counts against maxmemory"]
    F --> G{"maxmemory reached?"}
    G -->|"Eviction policy active"| H["Eviction begins - data loss"]
    G -->|"noeviction policy"| I["Write commands rejected with OOM"]
    G -->|"No maxmemory set"| J["RSS grows until OS OOM killer fires"]

Common causes

Quick checks

Run these read-only checks to identify whether output buffers are the problem and which clients are responsible.

# Check current output buffer limits
redis-cli CONFIG GET client-output-buffer-limit

# Check maxmemory-clients setting (Redis 7.0+)
redis-cli CONFIG GET maxmemory-clients

# Top clients by output buffer memory (omem)
redis-cli CLIENT LIST | awk -F'[= ]' '{for(i=1;i<=NF;i++) if($i=="omem") print $(i+1), $0}' | sort -rn | head -20

# Filter by client type
redis-cli CLIENT LIST TYPE normal | head -5
redis-cli CLIENT LIST TYPE pubsub | head -5

# Server-wide output buffer stats
redis-cli INFO clients | grep -E "client_recent_max_output|client_recent_max_input"

# Check if MONITOR is running
redis-cli INFO commandstats | grep -i monitor

# Memory overview
redis-cli INFO memory | grep -E "used_memory:|used_memory_overhead:|maxmemory:"

# Check Pub/Sub scale
redis-cli INFO stats | grep pubsub

How to diagnose it

1. Confirm output buffer pressure. Check INFO clients for client_recent_max_output_buffer. If this value is high relative to your maxmemory, output buffers are consuming meaningful memory. Cross-reference with used_memory and used_memory_overhead, the latter includes buffer memory.

2. Identify the offending client(s). Run CLIENT LIST and sort by omem. The omem field shows bytes in each client’s output buffer. Look for one or a small number of clients with disproportionately large values. Note their addr, age, idle, flags, and cmd fields for context.

3. Determine the client class. Use CLIENT LIST TYPE <normal|pubsub|replica> to filter. A normal client with high omem suggests a large response payload or a stalled read loop. A pubsub client with high omem means the subscriber cannot keep up with message fan-out. A replica with high omem means replication is backing up.

4. Check for MONITOR. Run INFO commandstats | grep monitor. If cmdstat_monitor shows calls, someone has an active MONITOR session. MONITOR copies every command’s output to the monitoring client, and under load the buffer can grow to gigabytes in minutes. There is no built-in alert for this. It must be checked manually or via CLIENT LIST.

5. Check the A flag in CLIENT LIST. The A flag marks a client scheduled for immediate disconnection, typically because it exceeded an output buffer limit. If you see clients with the A flag, buffer limits are being enforced but the clients keep reconnecting and re-triggering the problem.

6. Correlate with memory signals. Check whether used_memory is approaching maxmemory. If the server is at the memory limit, output buffer pressure compounds with normal data memory, triggering eviction or write rejection. Check evicted_keys rate and total_error_replies for confirmation.

7. Check for CVE-2025-21605 exposure. If auth is enabled but the instance is reachable from untrusted networks, unauthenticated clients can cause unlimited output buffer growth by triggering repeated NOAUTH responses. Check ACL LOG for auth failures from unexpected sources. Verify the Redis version is patched.

Metrics and signals to monitor

Fixes

Set output buffer limits for normal clients

The default client-output-buffer-limit normal 0 0 0 is unlimited. Set a limit that caps runaway consumption without disconnecting healthy clients under normal load.

# Live change - applies immediately
redis-cli CONFIG SET client-output-buffer-limit "normal 128mb 64mb 60"

This sets a 128MB hard limit and a 64MB soft limit sustained for 60 seconds for normal clients. The hard limit disconnects immediately. The soft limit disconnects after 60 seconds of continuous excess. Choose values based on your workload’s response size distribution.

To persist the change, add to redis.conf without quotes:

client-output-buffer-limit normal 128mb 64mb 60

Then run CONFIG REWRITE to persist any live changes.

CONFIG SET quoting gotcha. When using CONFIG SET at runtime, the value must be quoted because it contains spaces. The redis.conf file format does not need quotes. A mismatch causes a silent parse failure, leaving the old value in place.

Kill the offending slow consumer

If a single client is consuming excessive buffer memory and you need immediate relief:

# Kill by address
redis-cli CLIENT KILL ADDR <ip:port>

This is disruptive to that client. It will need to reconnect and reissue any in-flight commands. Use this when memory pressure is acute and you have identified the specific client.

Fix slow Pub/Sub subscribers

Pub/Sub has no backpressure. If a subscriber cannot keep up with PUBLISH rates, its output buffer accumulates the full fan-out backlog. Increasing client-output-buffer-limit pubsub is a blunt instrument that buys time but does not solve the problem.

The proper fix is to address the subscriber’s read loop. Common causes: synchronous processing in the subscriber that cannot keep up with message rate, GC pauses in the subscriber application, or network saturation between subscriber and Redis. If the subscriber genuinely cannot keep up, consider switching to Redis Streams with consumer groups, which provide backlog management and acknowledgment semantics.

Remove MONITOR sessions

If INFO commandstats shows cmdstat_monitor calls, find and kill the monitoring client. MONITOR is a debugging tool, not a production monitoring mechanism. Under any non-trivial load, it doubles output bandwidth and can OOM the instance via the monitor client’s output buffer.

# Find monitor clients by checking CLIENT LIST output
redis-cli CLIENT LIST
# Kill the offending client
redis-cli CLIENT KILL ADDR <ip:port>

After removing MONITOR, restrict the command via ACLs or rename-command to prevent recurrence.

Address replica buffer overflow

Replicas that fall behind during slow BGSAVE, network saturation, or COW pressure accumulate replication stream in their output buffer. If the client-output-buffer-limit replica hard limit is smaller than repl-backlog-size, the replica may succeed at partial sync but be immediately disconnected once the buffer limit kicks in.

Rule of thumb: the replica buffer hard limit should be at least as large as repl-backlog-size. Increase both together:

redis-cli CONFIG SET repl-backlog-size 104857600
redis-cli CONFIG SET client-output-buffer-limit "replica 512mb 128mb 60"

If replicas are repeatedly disconnecting and triggering full resyncs, also check sync_full and sync_partial_err counters.

Enable maxmemory-clients (Redis 7.0+)

maxmemory-clients sets an aggregate cap on all client-side memory, including query buffers, output buffers, and intermediates. It defaults to 0 (disabled). Setting it provides a backstop against total client buffer consumption.

# Set to a percentage of maxmemory
redis-cli CONFIG SET maxmemory-clients 10%

Replica and master connections are exempt from eviction under maxmemory-clients. Use CLIENT NO-EVICT ON to protect specific critical connections (monitoring, control-plane) from the eviction mechanism. Because CLIENT NO-EVICT applies to the current connection only, it must be reissued after any reconnection.

Prevention

• Set client-output-buffer-limit normal to a finite value. The default 0 0 0 means a single slow consumer can exhaust server memory. Choose a hard limit based on your largest expected response payload.
• Enable maxmemory-clients on Redis 7.0+. It provides an aggregate safeguard against total client buffer consumption that per-class limits alone cannot enforce.
• Periodically audit for MONITOR. Check INFO commandstats for cmdstat_monitor. Restrict the command via ACLs on production instances.
• Restrict network access to Redis. CVE-2025-21605 demonstrated that unauthenticated connections can cause unlimited output buffer growth. Ensure the instance is not reachable from untrusted networks and that the Redis version is patched.
• Set repl-backlog-size appropriately. The default 1MB is insufficient for production. At least 100MB for moderate write rates. The replica output buffer hard limit should be at least as large.
• Monitor omem per client. The largest single-client omem is a leading indicator. Alert when any client exceeds a threshold meaningful to your deployment.
• Apply CONFIG REWRITE after live changes. Any CONFIG SET without CONFIG REWRITE is lost on restart. Verify persistence after making buffer limit changes.

How Netdata helps

• Per-second used_memory and maxmemory tracking lets you see the exact moment output buffer pressure begins consuming memory headroom, before eviction or OOM rejection starts.
• client_recent_max_output_buffer from INFO clients surfaces the largest single-client output buffer without requiring manual CLIENT LIST parsing during an incident.
• evicted_keys rate correlated with connected_clients distinguishes dataset-driven eviction (keys growing) from buffer-driven eviction (clients accumulating).
• Network output bytes per second reveals asymmetric traffic patterns that precede output buffer accumulation, such as a large response fan-out or MONITOR doubling output bandwidth.
• Pub/Sub channel and pattern counts contextualize whether buffer pressure is coming from pubsub fan-out versus normal client reads.
• ML anomaly detection on memory and connection metrics flags the non-obvious case where used_memory climbs without a corresponding increase in keyspace size, which is the signature of buffer-driven memory consumption.

Netdata’s Redis monitoring with Netdata brings these signals together with per-second metrics and ML anomaly detection.

Related guides

• How Redis actually works in production: a mental model for operators
• Redis connected_clients climbing: connection leak detection
• Redis blocked_clients growing: dead consumers vs healthy queues
• Redis big keys: finding the giant key that blocks the event loop
• Redis NOAUTH / WRONGPASS authentication failures: ACL Log and credential drift
• Redis Can’t save in background: fork: Cannot allocate memory - diagnosis and fix