Redis insights

When redis.persist count is high relative to redis.db.expires, many keys lack TTLs and will accumulate indefinitely, causing memory growth. redis.keyspace.avg_ttl can indicate if TTL values are too long for workload patterns.

When redis.replication.repl_backlog_size is too small relative to write rate and network latency, replicas require full resync after brief disconnections, causing replication storms and increased master load.

When redis.keys.evicted rate increases significantly, Redis is evicting keys to stay within maxmemory limits, potentially causing cache miss storms and degraded application performance as hot data is prematurely evicted.

When Redis disconnects slow clients that can't keep up with output buffer, redis.clients.connected drops suddenly. This is often caused by clients with slow network connections or blocking on their end, especially for pub/sub subscribers or replicas.

When redis.memory.peak significantly exceeds redis.memory.used, the system has experienced memory pressure in the past that may recur. This indicates need for capacity planning or workload pattern investigation.

Certain Redis commands have O(N) complexity (KEYS, SMEMBERS, HGETALL, LRANGE without limit) and can cause latency spikes when executed on large data structures. redis.commands.usec tracking per command identifies hot spots.

When AOF persistence is enabled with appendfsync always or everysec, slow disk I/O can cause write latency spikes. redis.persistence.aof_last_rewrite_time_sec increasing significantly indicates AOF file growth without rewrite, amplifying disk I/O overhead.

Increasing redis.clients.blocked count indicates clients waiting on blocking operations (BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, BZPOPMIN, BZPOPMAX), which can cause connection pool exhaustion if client timeouts are too long or if producers aren't keeping up with consumers.

Redis Connection Pool Starvation from Blocking Patternswarning

When async endpoints make synchronous Redis calls, they hold connections longer than necessary while blocking the event loop, causing artificial connection pool exhaustion even when Redis server capacity is available.

Serial Execution Masking Redis Cache Effectivenesswarning

Event loop blocking creates false appearance of cache ineffectiveness - Redis cache hits are fast individually, but serial request processing prevents concurrent cache lookups from improving overall throughput during traffic bursts.

Misleading Infrastructure Health During Application-Layer Blockingwarning

When event loop blocking is the bottleneck, traditional infrastructure metrics (CPU, Redis ops, network I/O) appear healthy while request latency and timeouts increase - creating a diagnostic blind spot that delays root cause identification.

Redis Connection Saturation Stalls Async Event Loopcritical

When Redis connection pool exhausts under high concurrency, blocking Redis operations (even from async endpoints) stall the FastAPI event loop, causing serial-like request processing and tail latency spikes despite low CPU utilization.

Redis slowlog entries accumulating (redis.slowlog.length rising) can indicate operations blocking on network or disk I/O, exhausting connection pools and causing cascading failures in dependent services even when Redis CPU appears healthy.