redis.memory.used
Redis RSS memory usageSummary
Total bytes of memory allocated by Redis using its memory allocator, including all data, buffers, and internal structures. This is the primary memory metric for capacity monitoring. Compare against maxmemory to determine eviction risk and against RSS (resident set size) to calculate fragmentation ratio. Rapid growth indicates data accumulation, while steady-state usage above 80% of maxmemory suggests undersized capacity.
Interface Metrics (4)
Related Insights (5)
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.
High Redis memory fragmentation ratio (>1.5) causes actual memory usage to exceed redis.memory.maxmemory limits, triggering premature key evictions and reducing cache hit rates even when logical memory usage appears healthy.
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.
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.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.