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
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.
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.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
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.
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
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
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
It receives every command the server executes, at a large sustained cost on the one thread.
Instead:CLIENT KILL it, and use SLOWLOG instead.
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.
Connections share one execution thread, so more of them add contention rather than capacity.
Instead:Use a pool sized for concurrency.
Pooled clients hold idle connections on purpose. Closing them causes reconnect churn.
Instead:Leave them unless the count is growing.
CLIENT LIST is twenty-odd fields per connection. Three of them account for most real incidents.
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.
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.
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.
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.
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.