Redis Slow Query Log and Performance Tuning in Production

This is article 44 in the Big Data series. This article introduces Redis slow query log working principles and configuration methods, along with actionable production performance tuning strategies.

Full illustrated version (with screenshots): CSDN Original | Juejin

Slow Query Log Overview

Redis provides a mechanism similar to MySQL slow query logs, recording commands that exceed the execution time threshold to help locate performance bottlenecks.

Internal Implementation

Redis uses a fixed-length FIFO queue to store slow query records:

• When capacity is exceeded, the oldest records are automatically evicted
• Query time complexity is O(1)
• Only records command execution time, not including network transmission and queuing wait time

---

Configuration Parameters

slowlog-log-slower-than

Sets the recording threshold, in microseconds (1 second = 1,000,000 microseconds).

Value	Behavior
> 0	Records commands exceeding this execution time
0	Records all commands (for debugging)
< 0	Does not record any commands (disables slow log)

Default value: 10,000 microseconds (10ms) Production recommendation: 1,000–10,000 microseconds (1–10ms), adjust based on business SLA

# Dynamic modification (takes effect immediately, resets on restart)
CONFIG SET slowlog-log-slower-than 5000

# Write to config file (permanent effect)
# slowlog-log-slower-than 5000

slowlog-max-len

Sets the maximum number of entries in the slow log queue.

Default value: 128 Production recommendation: 1,000–10,000 (adjust higher based on available memory)

CONFIG SET slowlog-max-len 1000

---

Core Commands

# Get last N slow query records (default 10)
SLOWLOG GET [n]

# View current slow log entry count
SLOWLOG LEN

# Clear all slow logs
SLOWLOG RESET

SLOWLOG GET returns format (each record contains):

1. Unique ID
2. Unix timestamp of command execution
3. Execution time (in microseconds)
4. Command and argument list

---

Performance Optimization Strategies

Data Structure Layer

Problem	Solution
Verbose key naming	Use concise, meaningful key names
Storing large integers as String	Use Integer type (smaller memory)
KEYS * full scan	Use SCAN cursor iteration instead
HGETALL on large Hash	Use HMGET to specify fields or HSCAN for batch reading
Large values (>10KB)	Split into multiple small keys or compress before storing

Command Layer

Pipeline: Package multiple commands into a single network request to reduce RTT (Round-Trip Time):

// Jedis Pipeline example
Pipeline pipeline = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
    pipeline.set("key:" + i, "value:" + i);
}
pipeline.sync();

Batch commands: Prefer using MSET/MGET, HMSET/HMGET instead of multiple single commands.

Configuration Layer

• When enabling AOF, appendfsync everysec performs better than always
• Set maxmemory to prevent memory exhaustion triggering swap, which slows down all commands
• For large datasets, avoid frequent BGSAVE; consider increasing save trigger intervals

---

MONITOR Command

Real-time view of all commands received by Redis (including timestamp and client information):

MONITOR

Warning: MONITOR can significantly impact Redis throughput (up to 50% reduction), only for temporary debugging, never run in production long-term.

---

Monitoring System Recommendations

Production environment recommended monitoring stack:

Redis Instance → redis_exporter → Prometheus → Grafana

Core Monitoring Metrics

Metric	Description
used_memory	Memory usage, alert when approaching maxmemory
instantaneous_ops_per_sec	Commands per second, reflects load
connected_clients	Connection count, abnormal growth may indicate connection leaks
keyspace_hits/misses	Cache hit rate
rdb_last_bgsave_status	RDB persistence status
aof_current_size	AOF file size, triggers rewrite when too large
master_link_status	Master-replica replication health

---

Test Environment Quick Configuration

# Record all commands, keep only last 2 (for functional testing)
CONFIG SET slowlog-log-slower-than 0
CONFIG SET slowlog-max-len 2

# Execute some commands and view
SET foo bar
GET foo
SLOWLOG GET

Through the combination of slow query logs and monitoring systems, you can systematically discover and resolve Redis performance issues rather than relying on guesswork.