Redis过期键堆积是否影响性能？新手如何监控Redis与排查性能问题

Hey there! Let's tackle your Redis questions one by one—these are super common pain points, especially with legacy systems that rely heavily on caching. I’ve been in your shoes, so I’ll keep this practical and actionable.

1. Do a large number of expired keys hurt Redis performance? #

Absolutely, but the impact depends on how Redis handles expiration and the type of keys you’re dealing with:

• Lazy deletion overhead: Redis only deletes an expired key when someone tries to access it. If you have tons of expired keys that are still being requested (e.g., from stale client caches), each of those requests will trigger a deletion before returning a null, adding latency to individual commands.
• Periodic deletion CPU usage: Redis runs a background task every hz cycles (default 10) to scan a random subset of keys and delete expired ones. If most of your keys are expired, this task will spend more CPU cycles scanning and deleting, which can steal resources from serving client requests. You can tweak hz (up to 500) but be careful—higher values mean more background CPU usage.
• Big key expiration risks: If you have large expired keys (like huge hashes or lists), deleting them synchronously (even via lazy deletion) can block the Redis event loop for a few milliseconds, causing noticeable slowdowns for all clients.

Pro tip: If you’re on Redis 4.0+, enable lazy free (lazyfree-lazy-expire yes) to offload big key deletions to background threads, preventing event loop blocks.

2. What monitoring metrics should you track as a Redis newbie? #

Start with these core metrics to keep tabs on Redis health and responsiveness—you can get most of these via the INFO command in redis-cli:

• Memory health:
  • used_memory: Total memory Redis is using (keep an eye on this relative to your server’s available RAM).
  • used_memory_peak: Highest memory usage ever—if this is way higher than current usage, you might have memory fragmentation.
  • mem_fragmentation_ratio: Aim for 1.0-1.5. Values over 2 mean significant fragmentation (you might need to restart Redis or enable active defragmentation).
• Performance metrics:
  • instantaneous_ops_per_sec: Current number of commands processed per second—spikes here often correlate with slowdowns.
  • latency: Use redis-cli --latency to measure round-trip latency. Consistent latency over 10ms is a red flag.
  • commandstats: Run INFO commandstats to see which commands are taking the most time (look at usec_per_call). For example, if HGETALL has high average latency, you might be fetching too much data at once.
• Connection health:
  • connected_clients: Sudden spikes here could mean a leaky client or a misbehaving process.
  • blocked_clients: Clients stuck on commands like BLPOP—too many can indicate a problem with your queue logic.
• Key space health:
  • expired_keys: Total expired keys deleted—if this is way higher than expected, check your TTL settings.
  • evicted_keys: Keys evicted due to memory limits—if this is non-zero, your cache is too small or you’re storing non-cache data in Redis.

For monitoring tools, start simple:

• Use redis-cli --stat for real-time, condensed stats.
• Set up periodic INFO dumps to track trends over time (e.g., via a cron job that logs to a file).
• If you want a dashboard, Prometheus + Grafana works great, but it’s okay to stick to built-in tools until you’re comfortable.

3. How to identify which process is causing Redis slowdowns from high concurrency? #

Legacy systems with dozens of processes are tricky, but here’s how to narrow it down:

• Use CLIENT LIST to spot noisy clients: Run redis-cli CLIENT LIST and look for clients with:
  • High command counts (check fields like cmdstat_set or cmdstat_get).
  • Low idle time (they’re constantly sending requests).
  • The addr field shows the client IP/port—you can map this to a system process using ss -tp | grep <port> or netstat -tpn | grep <port> on your application server.
• Temporarily use MONITOR (carefully!): redis-cli MONITOR logs every command Redis receives. Run it for 10-30 seconds (any longer and it’ll slow Redis down) and pipe the output to a file:

  redis-cli MONITOR > redis_commands.log
  

  Then analyze the log to see which commands are flooding Redis, and look for patterns (e.g., a specific key prefix that ties to a cron job or service).
• Correlate time-based spikes: If slowdowns happen at specific times, cross-reference with your cron schedules. Use INFO stats to check when instantaneous_ops_per_sec spikes, then see which cron jobs run at that time.
• Check command-level latency: Use redis-cli --latency-history to track latency over time, and pair it with INFO commandstats to see which commands are causing delays. For example, if SET commands have high latency during spikes, the process writing those keys is the culprit.

Pro tip: Avoid running MONITOR on production Redis for extended periods—it adds significant overhead. Use it only for short debugging sessions.

内容的提问来源于stack exchange，提问作者Michael Hirschler