MEMORY-USAGE

# Check memory for a key
MEMORY USAGE mykey
(integer) 56

# With sample count for large collections
# Samples N random elements instead of all
MEMORY USAGE large-hash SAMPLES 1000
(integer) 1048576

SET tiny "x"
MEMORY USAGE tiny
(integer) 56

# Wait, "x" is 1 byte. Why 56?

# Breakdown:
# - Key name "tiny" (4 bytes)
# - Redis object header (~16 bytes)
# - String encoding overhead
# - Memory allocator overhead (rounding to jemalloc size class)

# Larger values have better efficiency
SET larger "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"  # 33 chars
MEMORY USAGE larger
(integer) 80  # Only 24 more bytes for 32 more chars

127.0.0.1:6379> MEMORY STATS
 1) "peak.allocated"
 2) (integer) 10485760
 3) "total.allocated"
 4) (integer) 8388608
 5) "startup.allocated"
 6) (integer) 1048576
 7) "replication.backlog"
 8) (integer) 1048576
 9) "clients.slaves"
10) (integer) 0
11) "clients.normal"
12) (integer) 49694
13) "aof.buffer"
14) (integer) 0
15) "keys.count"
16) (integer) 10000
17) "keys.bytes-per-key"
18) (integer) 500
19) "dataset.bytes"
20) (integer) 5000000
21) "dataset.percentage"
22) "59.604648590087890625"
...

127.0.0.1:6379> MEMORY DOCTOR

# Possible outputs:

# All good:
"Sam, I have no memory problems"

# Issues detected:
"High fragmentation detected. 
Consider restarting Redis or using MEMORY PURGE"

"Peak memory is much higher than current usage.
Run MEMORY PURGE to release memory back to OS"

"Many keys with no TTL are using significant memory.
Consider setting expiration on appropriate keys"

# Find biggest keys (redis-cli)
redis-cli --bigkeys

# Sample output:
# Biggest string: session:abc123 (5242880 bytes)
# Biggest hash: user:1001:profile (1048576 bytes)  
# Biggest list: queue:pending (10000 items)

# Memory analysis with sampling
redis-cli --memkeys

# Custom script to find top N by memory
redis-cli SCAN 0 COUNT 1000 | while read key; do
  size=$(redis-cli MEMORY USAGE "$key")
  echo "$size $key"
done | sort -rn | head -20

127.0.0.1:6379> INFO memory
# Memory
used_memory:8388608
used_memory_human:8.00M
used_memory_rss:12582912
used_memory_rss_human:12.00M
used_memory_peak:10485760
used_memory_peak_human:10.00M
mem_fragmentation_ratio:1.50
mem_fragmentation_bytes:4194304
mem_allocator:jemalloc-5.2.1

# Delete lots of data
DEL huge-key-1 huge-key-2 huge-key-3

# Memory might not drop immediately (allocator holds pages)
INFO memory | grep used_memory_rss_human
used_memory_rss_human:1.00G  # Still high

# Purge to release back to OS
MEMORY PURGE
OK

INFO memory | grep used_memory_rss_human
used_memory_rss_human:500.00M  # Better

# Bad: Many small strings
SET user:1001:name "John"
SET user:1001:email "john@example.com"
SET user:1001:age "30"
# 3 keys × ~50 bytes overhead each = ~150 bytes overhead

# Good: One hash
HSET user:1001 name "John" email "john@example.com" age "30"
# 1 key overhead, hash uses ziplist encoding for small data

# In redis.conf - tune ziplist/listpack thresholds

# Hashes: use ziplist for small hashes
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# Lists: use listpack
list-max-ziplist-size -2

# Sets: use intset for integer-only sets
set-max-intset-entries 512

# Sorted Sets: use ziplist for small zsets
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

// Compress large values before storing
const compressed = zlib.gzipSync(JSON.stringify(largeObject));
await redis.set('key', compressed);

// Decompress when reading
const data = JSON.parse(zlib.gunzipSync(await redis.getBuffer('key')));