Redis Ate All My RAM Again

Memory fragmentation is that sneaky bastard that kills your app while you're sleeping. You provision a 16GB Redis instance, store maybe 6GB of data, and somehow you're still getting OOM kills. What the fuck?

Black Friday 2022 - that's when I learned this lesson. We had 16GB allocated, around 4GB of actual data (I think it was 4.2GB but who's counting), and Redis kept getting murdered by the OOM killer. Spent the entire night debugging this shit. Turns out we had a fragmentation ratio of 3.4 - basically paying for 16GB to store less than 5GB of data. Math is fun when it's costing you money.

Redis uses jemalloc for memory allocation. It's supposed to be better than the standard malloc, right? Well, when your app dumps 500KB user profiles right next to tiny 50-byte session tokens, jemalloc creates a fucking mess. Memory looks like Swiss cheese - holes everywhere that can't be reused.

Understanding the Fragmentation Ratio

The fragmentation ratio is calculated as used_memory_rss / used_memory where:

• used_memory_rss is the actual RAM allocated by the OS to Redis
• used_memory is Redis's view of memory usage for stored data

## Check your current fragmentation ratio  
redis-cli INFO memory | grep fragmentation
mem_fragmentation_ratio:2.34

What These Numbers Actually Mean:

• Ratio 1.0-1.3: Healthy memory usage, minimal fragmentation
• Ratio 1.3-1.5: Moderate fragmentation, monitor closely
• Ratio 1.5-2.0: Serious fragmentation, performance impact likely
• Ratio >2.0: Critical fragmentation, immediate action required

A ratio over 2.0 means your Redis is wasting half your memory on nothing. That 3.4 ratio I mentioned? We were literally throwing money away - 240% waste for storing basic user sessions and product data.

The Real Causes of Memory Fragmentation

Unlike what Redis documentation suggests, fragmentation isn't just about "allocating and freeing objects of different sizes." Here's what actually fragments Redis memory in production:

Variable-Size Key Expiration Patterns

When you have mixed workloads with different key sizes and TTL patterns, memory gets fragmented as smaller keys expire between larger ones:

## This is exactly what killed us in production  
SET large_user_profile:12345 "{ massive JSON object 500KB }"
SET session:abc "small session token"  
SET large_user_profile:67890 "{ another massive JSON 500KB }"
EXPIRE session:abc 300  # Small key expires, leaves gap

## After expiration, you have: [500KB][gap][500KB]
## New 1MB allocation can't fit in the gap - fragments memory

Hash Resizing Under Load

Redis hashes automatically resize when they grow, but rehashing temporarily doubles memory usage and can leave fragmented blocks:

## Monitor hash resizing causing fragmentation
redis-cli --latency-history -i 1
## Look for latency spikes during high write volume

List and Stream Operations

Redis Lists and Streams are particularly fragmentation-prone because they allocate memory in chunks. When you trim lists or expire stream entries, the freed chunks often can't be reused efficiently.

Advanced Fragmentation Diagnosis

Memory Fragmentation Visualization: Visual representation showing how memory fragments over time - allocated blocks scattered throughout address space with unusable gaps between them, leading to inefficient memory utilization.

The basic INFO memory command doesn't tell the whole story. Use these Redis commands for detailed analysis:

## Get comprehensive memory statistics
redis-cli MEMORY STATS

## Sample output showing fragmentation sources:
total.allocated:       8589934592  # 8GB allocated
dataset.bytes:         6442450944  # 6GB actual data  
dataset.percentage:    75.0         # 75% efficiency
fragmentation.bytes:   2147483648  # 2GB fragmented
fragmentation.ratio:   1.33

## Analyze specific key memory usage
redis-cli MEMORY USAGE user:profile:12345
(integer) 524288  # This key uses 512KB

## Find memory-hungry keys
redis-cli --bigkeys --memkeys-samples 10000

The MEMORY DOCTOR command provides automated analysis, but it often misses cluster-specific fragmentation patterns.

Jemalloc vs. System Allocators

Redis uses jemalloc by default, which is generally better at handling fragmentation than glibc malloc, but it's not magic. Jemalloc's effectiveness depends on your allocation patterns:

## Check which allocator Redis is using
redis-cli INFO memory | grep allocator
mem_allocator:jemalloc-5.3.0

## Force different allocators during compilation
make MALLOC=libc      # Use system malloc (worse fragmentation)
make MALLOC=jemalloc  # Use jemalloc (default, better)

In production, jemalloc beats system malloc for fragmentation handling, but when you're constantly pushing 64KB-1MB objects, both allocators will fragment your memory to hell. Tested this on Redis 7.0.8 last month - same shit, different version number.

Memory Fragmentation in Redis Clusters

Cluster deployments fragment memory differently than standalone instances. Slot migration operations temporarily double memory usage for migrated keys, and failed migrations leave orphaned allocations:

## Check cluster-specific fragmentation
for node in redis-node-{1..6}; do
  echo "=== $node ==="
  redis-cli -h $node INFO memory | grep -E "(fragmentation|used_memory)"
done

## Look for nodes with significantly different fragmentation ratios
## This indicates uneven slot distribution or failed migrations

The Active Defragmentation Trap

Redis 4+ includes active defragmentation, which sounds like a silver bullet but can actually make problems worse:

## Active defrag configuration (be careful!)
CONFIG SET activedefrag yes
CONFIG SET active-defrag-ignore-bytes 100mb
CONFIG SET active-defrag-threshold-lower 10
CONFIG SET active-defrag-cycle-min 1
CONFIG SET active-defrag-cycle-max 25

Why Active Defrag Often Backfires:

• Blocks the main thread: Defragmentation pauses command processing
• Triggers timeouts in clusters: Other nodes think the defragging node has failed
• CPU intensive: Can cause thermal throttling on cloud instances
• Temporary fragmentation increase: Moving memory around fragments it more initially

Active defragmentation during high traffic is like doing surgery on a running engine while it's on fire. We enabled it during a 2am production incident thinking it would help - made everything ten times worse. Latency spiked, timeouts everywhere, the whole cluster went to shit. Took us offline for another 30 minutes.

The Redis docs don't bother mentioning that defrag blocks the main thread. Thanks, guys.

Memory Fragmentation Monitoring Alerts

Set up monitoring on these fragmentation indicators before problems occur:

## Critical alerting thresholds
mem_fragmentation_ratio > 1.5     # Memory efficiency dropping
used_memory_rss_human > 80% of available RAM  # Running out of space
mem_fragmentation_bytes > 1GB     # Absolute waste is significant

## Warning thresholds  
mem_fragmentation_ratio > 1.3     # Early fragmentation warning
latest_fork_usec > 10000          # Fork operations becoming slow (indicates memory pressure)

Set up comprehensive memory alerting and metric collection before problems occur.

When to Restart vs. Fix Fragmentation

Sometimes restarting Redis is the fastest solution, but it's not always feasible:

Restart When:

• Fragmentation ratio >2.5 and climbing
• Active defragmentation doesn't help after 24 hours
• Memory efficiency drops below 50%
• You can afford the downtime (seconds for small datasets, minutes for large)

Try to Fix When:

• Fragmentation ratio 1.5-2.5 and stable
• Production system can't afford restart
• You have replica nodes that can take over temporarily

Nobody tells you this: once you have severe fragmentation, fixing it without a restart is like trying to unscramble eggs. I've wasted entire weekends trying to fix fragmentation on running instances. Don't be me.

RedisInsight helps visualize the fragmentation, but by the time you're pulling up pretty charts, you're already fucked.

Anyway, diagnosing fragmentation is just step one. Next up - stopping the OOM killer from murdering your Redis instance at 3am.

Exit code 137 is Linux saying "your Redis got too greedy, so I killed it." This happens because most people either run Redis with no memory limits, or they set maxmemory way too high and think that fixes everything.

The Linux OOM killer doesn't give a fuck about your uptime. When system memory runs low, it looks for the biggest memory hog and sends SIGKILL. No negotiation, no graceful shutdown, just death. I've been woken up at 3am by this exact bullshit more times than I care to remember.

Understanding the OOM Kill Chain of Events

When Redis gets OOM-killed, here's the actual sequence that leads to disaster:

1. Memory pressure builds: Redis approaches physical RAM limits
2. System starts swapping: Performance degrades dramatically as Redis data hits swap
3. OOM killer evaluates processes: Kernel identifies Redis as the memory hog
4. SIGKILL sent to Redis: Process terminates immediately, no graceful shutdown
5. Data loss occurs: Any unsaved data since last persistence point is gone
6. Application failures cascade: All Redis-dependent services start failing

## Check if your Redis was OOM-killed
dmesg | grep -i "killed process"
## Example output:
## [timestamp] Out of memory: Kill process 1234 (redis-server) score 900 or sacrifice child

## Check OOM killer score (higher = more likely to be killed)
cat /proc/$(pgrep redis-server)/oom_score

Check dmesg after any unexpected Redis restart - you'll probably find the smoking gun. This is the first thing I check when Redis mysteriously dies.

Configuring Proper Memory Limits

The biggest mistake I see is not setting maxmemory or setting it too high. Redis should never be allowed to consume all available system RAM:

## WRONG - No memory limit (this will kill your server)
## maxmemory 0  # This is the dangerous default

## CORRECT - Leave headroom for OS and other processes
maxmemory 6gb        # On an 8GB system
maxmemory-policy allkeys-lru

## Check current memory configuration
redis-cli CONFIG GET maxmemory*

Production Memory Sizing Rule:

• Physical RAM: Total server memory
• OS + Other Services: Reserve 15-20% (1.5-2GB on 8GB system)
• Redis maxmemory: 70-80% of physical RAM maximum
• Safety buffer: Keep 500MB-1GB extra headroom

Leave headroom or you'll be debugging OOM kills at 3am in your underwear like I've done way too many fucking times.

Memory Eviction Policies That Work in Production

Redis offers eight eviction policies, but only a few work reliably in production scenarios:

## Production-tested eviction policies
maxmemory-policy allkeys-lru     # Evict least recently used keys (most common)
maxmemory-policy allkeys-lfu     # Evict least frequently used (better for hot data)
maxmemory-policy volatile-ttl    # Evict keys with shortest TTL (if you set TTLs)

## Avoid these policies in production
maxmemory-policy noeviction      # NEVER use this - causes OOM kills
maxmemory-policy allkeys-random  # Poor performance, unpredictable behavior

What Actually Works:

allkeys-lru: This is the safe default. Evicts least recently used keys when memory fills up. Not perfect, but it won't randomly break your app at 2am.

allkeys-lfu: Only use this if you have clear hot/cold data patterns. It's supposedly smarter than LRU but way more complex. We tried LFU for maybe 3 weeks and went back to LRU because debugging cache misses turned into a full-time job.

volatile-ttl: Only evicts keys that have TTLs set. Sounds good in theory, but if you forget to set TTLs on some keys, Redis can't evict anything and you get OOM errors.

The Noeviction Trap

Never use maxmemory-policy noeviction in production. I've seen this mistake kill entire applications:

## This configuration is a production killer
maxmemory 8gb
maxmemory-policy noeviction

## What happens when memory hits 8GB:
## 1. Redis stops accepting writes
## 2. Applications start getting \"OOM command not allowed\" errors  
## 3. Read-only mode breaks application assumptions
## 4. Users can't login, shop, or perform any write operations

The noeviction policy exists for compliance scenarios, but requires external memory management that most applications don't implement properly.

Swap Configuration for Redis

Never let Redis use swap. Swapping Redis data to disk destroys performance and often leads to cascading failures:

## Disable swap completely (recommended for Redis servers)
sudo swapoff -a
sudo vim /etc/fstab  # Remove swap entries

## Or tune swappiness to prefer evicting other processes
sudo sysctl vm.swappiness=1
echo 'vm.swappiness = 1' >> /etc/sysctl.conf

## Monitor swap usage
free -h
              total        used        free      shared  buff/cache   available
Mem:           7.8G        6.2G        1.6G         0B        0B        1.6G
Swap:            0B          0B          0B  # Good - no swap active

Swapping Redis data destroys performance. Just disable swap completely on Redis servers. Learned this when our Redis latency went from 2ms to 2 fucking seconds during a memory crunch. Users were not happy.

Overcommit Memory Settings

Linux memory overcommit can cause OOM kills even when Redis is within configured limits:

## Check current overcommit settings
cat /proc/sys/vm/overcommit_memory
## 0 = Heuristic (default, can cause issues)
## 1 = Always allow (dangerous)
## 2 = Never overcommit (safest for Redis)

## Recommended setting for Redis servers
echo 1 > /proc/sys/vm/overcommit_memory
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf

## Also increase overcommit ratio if using mode 2
echo 80 > /proc/sys/vm/overcommit_ratio
echo 'vm.overcommit_ratio = 80' >> /etc/sysctl.conf

Fuck this up and Redis dies even when it's being well-behaved. Spent 4 hours debugging this exact issue on Ubuntu 20.04. Four. Hours.

Memory Monitoring and Alerting

Set up proactive monitoring before memory problems occur:

#!/bin/bash
## Redis memory monitoring script
REDIS_HOST=\"localhost\"
REDIS_PORT=\"6379\"

## Get memory stats
USED_MEMORY=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT INFO memory | grep used_memory_human | cut -d: -f2 | tr -d '\r')
MAX_MEMORY=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT CONFIG GET maxmemory | tail -1)
FRAGMENTATION=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT INFO memory | grep mem_fragmentation_ratio | cut -d: -f2 | tr -d '\r')

## System memory  
SYSTEM_MEMORY=$(free -b | awk '/^Mem:/{print $2}')
AVAILABLE_MEMORY=$(free -b | awk '/^Mem:/{print $7}')

echo \"Redis Memory: $USED_MEMORY / $MAX_MEMORY\"
echo \"System Available: $(($AVAILABLE_MEMORY / 1024 / 1024))MB\"
echo \"Fragmentation Ratio: $FRAGMENTATION\"

## Alert thresholds
if (( $(echo \"$FRAGMENTATION > 1.5\" | bc -l) )); then
  echo \"WARNING: High fragmentation ratio: $FRAGMENTATION\"
fi

if (( $AVAILABLE_MEMORY < 1073741824 )); then  # Less than 1GB available
  echo \"CRITICAL: Low system memory: $(($AVAILABLE_MEMORY / 1024 / 1024))MB\"
fi

Container Memory Limits

Running Redis in Docker or Kubernetes requires different memory management strategies:

## Docker Compose with proper memory limits
services:
  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 1024mb --maxmemory-policy allkeys-lru
    deploy:
      resources:
        limits:
          memory: 1.5G        # Container limit > Redis maxmemory
        reservations:
          memory: 1G

## Kubernetes Redis deployment with memory governance
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  template:
    spec:
      containers:
      - name: redis
        image: redis:7
        args:
          - redis-server
          - --maxmemory
          - \"1073741824\"      # 1GB Redis limit
          - --maxmemory-policy
          - allkeys-lru
        resources:
          limits:
            memory: \"1.5Gi\"   # 1.5GB container limit
          requests:
            memory: \"1Gi\"     # Guaranteed memory

Container memory limits should always be higher than your Redis maxmemory setting. Leave room for overhead. Docker will murder your container if it hits the limit - learned this one the hard way too.

Recovery from OOM Kills

When Redis gets OOM-killed, follow this recovery procedure:

## 1. Check system memory availability
free -h
df -h  # Also check disk space for RDB/AOF files

## 2. Verify Redis configuration before restart
redis-server --test-config /etc/redis/redis.conf

## 3. Start Redis with temporary lower memory limit
redis-server --maxmemory 4gb --maxmemory-policy allkeys-lru

## 4. Monitor memory usage during startup
watch -n 1 'redis-cli INFO memory | grep -E \"(used_memory_human|fragmentation)\"

## 5. Gradually increase limits as system stabilizes
redis-cli CONFIG SET maxmemory 6442450944  # 6GB

Memory Optimization for Different Workloads

Cache-Heavy Workloads:

maxmemory 70% of available RAM
maxmemory-policy allkeys-lru
save \"\"  # Disable persistence for pure cache

Session Storage:

maxmemory 60% of available RAM  # Sessions can be recreated
maxmemory-policy volatile-lru   # Prefer removing expired sessions
save 900 1  # Light persistence for session recovery

Analytics/Counters:

maxmemory 80% of available RAM  # Data is valuable
maxmemory-policy allkeys-lfu    # Keep frequently accessed metrics
appendonly yes  # Full persistence for data integrity

Pick what fits your use case, don't just copy-paste configs from some random tutorial.

Now let's talk about the specific error scenarios that'll fuck up your day.

Memory monitoring is the difference between catching problems early and getting woken up at 3am because everything's on fire. Trust me, I've been on the wrong side of that wake-up call way too many times.

Most monitoring setups track every possible metric and spam you with alerts until you ignore everything important. Focus on the few metrics that actually tell you when Redis is about to shit the bed.

The Essential Memory Metrics That Actually Matter

Most monitoring setups track dozens of Redis metrics, but only a few predict memory-related failures:

#!/bin/bash
## Critical memory monitoring script for production
REDIS_CLI="redis-cli"

## Memory efficiency metrics
USED_MEMORY=$($REDIS_CLI INFO memory | grep '^used_memory:' | cut -d: -f2 | tr -d '\r')
USED_MEMORY_RSS=$($REDIS_CLI INFO memory | grep '^used_memory_rss:' | cut -d: -f2 | tr -d '\r')
FRAGMENTATION_RATIO=$($REDIS_CLI INFO memory | grep '^mem_fragmentation_ratio:' | cut -d: -f2 | tr -d '\r')
MAX_MEMORY=$($REDIS_CLI CONFIG GET maxmemory | tail -1)

## System memory context
SYSTEM_TOTAL=$(free -b | awk '/^Mem:/{print $2}')
SYSTEM_AVAILABLE=$(free -b | awk '/^Mem:/{print $7}')

echo "=== Redis Memory Health Check ==="
echo "Used Memory: $(($USED_MEMORY / 1024 / 1024))MB"
echo "RSS Memory: $(($USED_MEMORY_RSS / 1024 / 1024))MB" 
echo "Max Memory: $(($MAX_MEMORY / 1024 / 1024))MB"
echo "Fragmentation Ratio: $FRAGMENTATION_RATIO"
echo "System Available: $(($SYSTEM_AVAILABLE / 1024 / 1024))MB"

## Calculate memory utilization percentage
if [ $MAX_MEMORY -gt 0 ]; then
    UTILIZATION=$((USED_MEMORY * 100 / MAX_MEMORY))
    echo "Memory Utilization: ${UTILIZATION}%"
    
    # Critical alerts
    if [ $UTILIZATION -gt 85 ]; then
        echo "CRITICAL: Memory utilization >85% - OOM risk high"
    elif [ $UTILIZATION -gt 75 ]; then
        echo "WARNING: Memory utilization >75% - monitor closely" 
    fi
fi

## Fragmentation alerts
if (( $(echo "$FRAGMENTATION_RATIO > 2.0" | bc -l) )); then
    echo "CRITICAL: Fragmentation ratio >2.0 - restart recommended"
elif (( $(echo "$FRAGMENTATION_RATIO > 1.5" | bc -l) )); then
    echo "WARNING: Fragmentation ratio >1.5 - investigate patterns"
fi

Memory utilization over 85% and fragmentation ratio over 1.5 - those are the two alerts that matter. Everything else is noise that'll get you ignored when something actually breaks.

Setting Up Prometheus and Grafana for Redis Memory Monitoring

If you're using Prometheus, the Redis exporter works well:

## docker-compose.yml for Redis monitoring stack
version: '3.8'
services:
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    command: redis-server --maxmemory 1gb --maxmemory-policy allkeys-lru
    
  redis-exporter:
    image: oliver006/redis_exporter:latest
    ports:
      - "9121:9121"
    environment:
      REDIS_ADDR: "redis://redis:6379"
      REDIS_EXPORTER_INCLUDE_SYSTEM_METRICS: "true"
    depends_on:
      - redis

  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    
  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

## prometheus.yml configuration
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'redis'
    static_configs:
      - targets: ['redis-exporter:9121']
    scrape_interval: 5s  # More frequent for memory metrics

Grafana has decent Redis dashboards you can import instead of building from scratch. Don't waste weeks building custom dashboards like I did - learn from my mistakes.

Memory Alerting Rules That Actually Work

Most Redis alerting rules are either too noisy (constant false positives) or too quiet (miss real problems). Here are production-tested alert rules:

## prometheus-alerts.yml
groups:
- name: redis-memory
  rules:
  # Critical: Redis about to hit memory limit
  - alert: RedisMemoryHigh
    expr: redis_memory_used_bytes / redis_config_maxmemory_bytes > 0.85
    for: 2m
    labels:
      severity: critical
    annotations:
      summary: "Redis memory usage critical on {{ $labels.instance }}"
      description: "Redis memory usage is {{ $value | humanizePercentage }} of configured limit"

  # Warning: Memory fragmentation becoming problematic  
  - alert: RedisMemoryFragmentation
    expr: redis_memory_fragmentation_ratio > 1.5
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "Redis memory fragmentation high on {{ $labels.instance }}"
      description: "Memory fragmentation ratio is {{ $value }}, consider investigating allocation patterns"

  # Critical: System running low on memory
  - alert: RedisSystemMemoryLow
    expr: (redis_memory_used_rss_bytes / on(instance) node_memory_MemTotal_bytes) > 0.80
    for: 3m
    labels:
      severity: critical
    annotations:
      summary: "Redis consuming too much system memory on {{ $labels.instance }}"
      description: "Redis RSS memory is {{ $value | humanizePercentage }} of total system memory"

  # Warning: Fork operations becoming slow (memory pressure indicator)
  - alert: RedisSlowFork
    expr: redis_latest_fork_usec > 10000
    for: 1m
    labels:
      severity: warning
    annotations:
      summary: "Redis fork operations slow on {{ $labels.instance }}"
      description: "Latest fork took {{ $value }}μs, indicating memory pressure"

CloudWatch Monitoring for AWS ElastiCache

If you're using managed Redis, set up CloudWatch alerts on these specific metrics:

## AWS CLI commands to create ElastiCache memory alerts
aws cloudwatch put-metric-alarm \
  --alarm-name "Redis-Memory-High" \
  --alarm-description "Redis memory utilization >85%" \
  --metric-name DatabaseMemoryUsagePercentage \
  --namespace AWS/ElastiCache \
  --statistic Average \
  --period 300 \
  --threshold 85 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=CacheClusterId,Value=your-redis-cluster \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:region:account:redis-alerts

aws cloudwatch put-metric-alarm \
  --alarm-name "Redis-Memory-Fragmentation" \
  --alarm-description "Redis memory fragmentation >1.5" \
  --metric-name MemoryFragmentationRatio \
  --namespace AWS/ElastiCache \
  --statistic Average \
  --period 300 \
  --threshold 1.5 \
  --comparison-operator GreaterThanThreshold \
  --dimensions Name=CacheClusterId,Value=your-redis-cluster \
  --evaluation-periods 3

If you're on AWS, ElastiCache has built-in memory alerts you should enable. Would've saved me a week of building custom CloudWatch alerts if I'd known this existed.

Memory Trend Analysis and Capacity Planning

Understanding memory growth patterns helps prevent surprises:

#!/usr/bin/env python3
## Redis memory trend analysis script
import redis
import time
import json
from datetime import datetime, timedelta

def collect_memory_metrics():
    r = redis.Redis(host='localhost', port=6379, decode_responses=True)
    
    info = r.info('memory')
    stats = r.info('stats') 
    
    return {
        'timestamp': datetime.now().isoformat(),
        'used_memory': info['used_memory'],
        'used_memory_rss': info['used_memory_rss'],
        'fragmentation_ratio': info['mem_fragmentation_ratio'],
        'total_commands_processed': stats['total_commands_processed'],
        'keyspace_hits': stats['keyspace_hits'],
        'keyspace_misses': stats['keyspace_misses']
    }

def analyze_growth_rate(metrics_history):
    """Calculate daily memory growth rate"""
    if len(metrics_history) < 2:
        return 0
    
    first = metrics_history[0]
    last = metrics_history[-1]
    
    time_diff_hours = (
        datetime.fromisoformat(last['timestamp']) -
        datetime.fromisoformat(first['timestamp'])
    ).total_seconds() / 3600
    
    memory_diff = last['used_memory'] - first['used_memory']
    
    # Convert to daily growth rate
    daily_growth = (memory_diff / time_diff_hours) * 24
    
    return daily_growth

## Track daily growth and predict when you'll hit limits
if __name__ == "__main__":
    # Run this daily to track trends
    current_metrics = collect_memory_metrics()
    print(f"Memory usage: {current_metrics['used_memory'] / 1024 / 1024:.2f}MB")
    print(f"Fragmentation: {current_metrics['fragmentation_ratio']:.2f}")

Kubernetes Redis Memory Monitoring

For Redis running in Kubernetes, monitor both container and pod-level metrics:

## ServiceMonitor for Prometheus Operator
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: redis-memory-monitoring
spec:
  selector:
    matchLabels:
      app: redis
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

## PrometheusRule for Redis memory alerts in Kubernetes
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: redis-memory-alerts
spec:
  groups:
  - name: redis.memory
    rules:
    - alert: RedisContainerMemoryLimit
      expr: |
        (
          container_memory_working_set_bytes{container="redis"} /
          container_spec_memory_limit_bytes{container="redis"}
        ) > 0.85
      for: 2m
      labels:
        severity: critical
      annotations:
        summary: "Redis container near memory limit"
        description: "Redis container {{ $labels.pod }} using {{ $value | humanizePercentage }} of memory limit"

    - alert: RedisMemoryRequestVsUsage
      expr: |
        (
          container_memory_working_set_bytes{container="redis"} /
          kube_pod_container_resource_requests{resource="memory",container="redis"}
        ) > 1.5
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Redis using much more memory than requested"
        description: "Redis pod {{ $labels.pod }} using {{ $value }}x its memory request"

Kubernetes adds another layer of memory limits to watch. Because one set of memory limits wasn't confusing enough, right?

Custom Memory Health Checks

Redis Insight Memory Analysis: GUI-based memory analysis tool providing visual insights into key size distribution, memory usage patterns, and optimization recommendations for production Redis instances.

Implement application-level health checks that understand Redis memory states:

#!/usr/bin/env python3
## Redis memory health check endpoint
from flask import Flask, jsonify
import redis
import json

app = Flask(__name__)

def get_redis_memory_health():
    try:
        r = redis.Redis(host='localhost', port=6379, decode_responses=True)
        
        info = r.info('memory')
        config = r.config_get('maxmemory')
        
        max_memory = int(config['maxmemory'])
        used_memory = info['used_memory']
        fragmentation = info['mem_fragmentation_ratio']
        
        # Calculate health score
        memory_utilization = used_memory / max_memory if max_memory > 0 else 0
        fragmentation_penalty = max(0, fragmentation - 1.0) * 0.5
        
        health_score = 100 - (memory_utilization * 100) - (fragmentation_penalty * 100)
        health_score = max(0, min(100, health_score))
        
        status = "healthy"
        if health_score < 50:
            status = "critical"
        elif health_score < 70:
            status = "warning"
            
        return {
            'status': status,
            'health_score': round(health_score, 2),
            'memory_utilization_percent': round(memory_utilization * 100, 2),
            'fragmentation_ratio': fragmentation,
            'used_memory_mb': round(used_memory / 1024 / 1024, 2),
            'max_memory_mb': round(max_memory / 1024 / 1024, 2) if max_memory > 0 else None
        }
        
    except Exception as e:
        return {
            'status': 'error',
            'error': str(e),
            'health_score': 0
        }

@app.route('/health/redis-memory')
def redis_memory_health():
    health = get_redis_memory_health()
    status_code = 200
    
    if health['status'] == 'critical':
        status_code = 503
    elif health['status'] == 'warning':
        status_code = 429
    elif health['status'] == 'error':
        status_code = 500
        
    return jsonify(health), status_code

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=8080)

Log Analysis for Memory Issues

Configure structured logging to capture memory-related events:

## redis.conf logging configuration
loglevel notice
logfile /var/log/redis/redis-server.log

## Log these memory-related events
redis-cli CONFIG SET slowlog-log-slower-than 10000
redis-cli CONFIG SET slowlog-max-len 1000

#!/bin/bash
## Log analysis script for Redis memory issues
LOG_FILE="/var/log/redis/redis-server.log"

echo "=== Redis Memory-Related Log Analysis ==="

## Check for OOM warnings
echo "OOM Warnings:"
grep -i "memory\|oom" $LOG_FILE | tail -10

## Check for slow operations (often memory-related)
echo -e "
Slow Operations:"
redis-cli SLOWLOG GET 10 | grep -A5 -B5 "DEL\|FLUSHDB\|FLUSHALL"

## Check for persistence issues (memory pressure affects saves)
echo -e "
Persistence Issues:"
grep -i "background save\|fork\|rdb\|aof" $LOG_FILE | tail -10

## Check for client disconnections (memory pressure can cause timeouts)
echo -e "
Client Disconnections:"
grep -i "disconnected\|timeout" $LOG_FILE | tail -10

Integration with APM Tools

Integrate Redis memory metrics with Application Performance Monitoring tools:

## New Relic custom metric example
import newrelic.agent

@newrelic.agent.function_trace()
def track_redis_memory_metrics():
    r = redis.Redis()
    info = r.info('memory')
    
    # Send custom metrics to New Relic
    newrelic.agent.record_custom_metric('Redis/Memory/Used', info['used_memory'])
    newrelic.agent.record_custom_metric('Redis/Memory/RSS', info['used_memory_rss'])
    newrelic.agent.record_custom_metric('Redis/Memory/Fragmentation', info['mem_fragmentation_ratio'])

## DataDog StatsD example
from datadog import DogStatsDClient
statsd = DogStatsDClient()

def send_redis_memory_metrics():
    r = redis.Redis()
    info = r.info('memory')
    
    statsd.gauge('redis.memory.used', info['used_memory'])
    statsd.gauge('redis.memory.rss', info['used_memory_rss'])  
    statsd.gauge('redis.memory.fragmentation_ratio', info['mem_fragmentation_ratio'])

Don't overthink monitoring - track memory usage, fragmentation ratio, set up alerts. Done. I wasted 3 weeks building the "perfect" monitoring dashboard that nobody ever looked at. Don't be me.

Good monitoring catches memory issues before they become 3am wake-up calls. Now let's talk about the resources that actually help when shit hits the fan.