Redis CLIENT LIST Analyzer

Paste the output of redis-cli CLIENT LIST. Two fields carry most of the signal: flags=O marks a MONITOR session receiving every command the server runs, and omem is output the client has not read.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Analyze. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A forgotten MONITOR

Every command the server runs is being streamed to this client

id=9 addr=10.0.0.9:4444 age=90000 idle=0 flags=O db=0 omem=0 cmd=monitor

A slow subscriber

Output the client has not read, which will end in a disconnect

id=4 addr=10.0.0.6:59235 age=100 idle=0 flags=N db=0 omem=41943040 cmd=subscribe

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Leaving a MONITOR session running

    It receives every command the server executes, at a large sustained cost on the one thread.

    Instead:CLIENT KILL it, and use SLOWLOG instead.

  2. Raising client-output-buffer-limit to stop disconnects

    The disconnect is the symptom. Raising the limit moves the failure into the server's memory, which is outside maxmemory.

    Instead:Fix why the client is not reading.

  3. Opening a connection per request

    Connections share one execution thread, so more of them add contention rather than capacity.

    Instead:Use a pool sized for concurrency.

  4. Setting a server-side timeout to clear idle connections

    Pooled clients hold idle connections on purpose. Closing them causes reconnect churn.

    Instead:Leave them unless the count is growing.

The fields that explain an unexplained slowdown

CLIENT LIST is twenty-odd fields per connection. Three of them account for most real incidents.

flags=O is a MONITOR session, and it is expensive

MONITOR streams every command the server executes to that client. On a single-threaded server that is a large sustained cost, and a forgotten debugging session is a classic cause of a slowdown nobody can explain. SLOWLOG and LATENCY answer the same questions for almost nothing.

omem is unread output, and it is outside maxmemory

It is memory the server has produced that the client has not consumed. When it crosses client-output-buffer-limit the server disconnects that client, which the application sees as a dropped connection rather than as backpressure. Raising the limit hides the symptom and moves the failure into the server's own memory.

A slow pub/sub subscriber is the usual cause

Pub/sub has no acknowledgement and no flow control, so a subscriber that reads slower than the publisher writes accumulates output buffer until the limit disconnects it. The default limit for pubsub clients is deliberately lower than for normal ones for exactly this reason.

Many connections from one host means no pooling

Every connection costs a file descriptor and its own buffers, and they all share the single thread that executes commands. Extra connections add contention rather than throughput. A count that grows over time rather than settling is a leak.

Idle is usually fine

Pooled clients hold idle connections deliberately. A long idle time is only interesting when the count keeps climbing or the buffers are large. Setting the server timeout to close them produces reconnect churn on a healthy pool.