Technologies/PostgreSQL/redis.memory.used
PostgreSQLPostgreSQLMetric

redis.memory.used

Redis RSS memory usage
Dimensions:None

Summary

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.

Related Insights (5)
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.

Memory Fragmentation Amplifies Cache Eviction Pressurewarning

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.

Peak Memory Exceeded Indicates Historical Capacity Issuesinfo

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.

High Eviction Rate Indicates Memory Pressurewarning

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.

Expiring Keys Without TTL Monitoring Causes Memory Leakswarning

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.