Skip to content 
The Redis Slow Log shows me exactly which commands are blocking the server thread and how long they take to execute (in microseconds), allowing me to pinpoint and eliminate sources of latency. With robust thresholds, clean exports, and correlated metrics, I optimize the Performance sustainable.
Key points
Before I dive deeper, I identify the key focus areas so that I can proceed in a targeted manner. I focus on clear configurations, recurring patterns, and effective countermeasures. I also pay attention to how these relate to the client’s context and the system environment. This allows me to achieve a consistent Analysis without any noise. Afterward, I directly apply these insights to code, data model, and monitoring adjustments.
- Threshold and choose a log length that makes sense
- Patterns on Time, Recognizing Commands and Clients
- Slow commands due to Alternatives replace
- Data Model and Caching tighten
- Slow Logins Monitoring integrate
Slow Log: A Brief Explanation of How It Works
I see the Slow Log as a focused perspective on pure Execution time of a command in Redis's single thread. The server automatically writes an entry as soon as the duration exceeds the threshold set by `slowlog-log-slower-than` in microseconds. Each record provides me with the ID, Unix timestamp, execution time, command with arguments, client IP/port, and, optionally, a client name. The Slow Log intentionally excludes network I/O and response transmission, allowing me to see the thread’s actual blocking time. It is precisely this separation that helps me clearly distinguish logical causes from network or client latency and the Cause to narrow it down better.
Configuration: Threshold and Log Length
To get off to a productive start, I set the Threshold I often set it to 10,000 microseconds (approx. 10 ms); during testing, I temporarily lower it to capture finer details. I control the number of stored entries using `slowlog-max-len`, typically between 128 and 4,096, so that load spikes remain clearly visible. I change both values either in `redis.conf` or at runtime using `CONFIG SET`, which allows me to have flexible diagnostic windows. Before major load tests, I lower the threshold; once the tests are complete, I raise it back to a realistic production value. This way, I keep the log lean without losing important Signals to lose.
| Setting/Command | Meaning | Practical value |
|---|---|---|
| slowlog-log-slower-than | Threshold value in microseconds for entries | Prod: 10,000 µs; Test: 1,000–5,000 µs |
| slowlog-max-len | Maximum number of stored entries | 128–4,096 entries, depending on the volume |
| SLOWLOG GET N | Displays the last N records | N = 10–100 for ad hoc checks |
| SLOWLOG LEN | Returns the current log length | Check regularly |
| SLOWLOG RESET | Clear the log | Export/back up first |
Reading the Slow Log in Everyday Life
In my daily work, I retrieve the most recent entries using SLOWLOG GET and use SLOWLOG LEN to check how much slow commands are accumulating before clearing the log with SLOWLOG RESET if necessary. Exporting the log before the reset prevents me from losing valuable History lose, especially when I want to compare trends over several days. In cluster setups, I include every instance and every replica, since the slow log is instance-specific and otherwise blind spots remain. For structured analysis, I link the entries to client information such as IP, port, and the assigned name so that I can uniquely identify the source in the application code. Additionally, I review INFO statistics to evaluate frequencies and latencies in the context of overall usage.
From Events to Patterns: A Systematic Analysis
First, I'll look at the most common commands that stand out due to their high Runtime and then check how often they occur in total on the instance. A command that rarely exceeds the threshold is less of a problem than one that is just slightly above the threshold but runs thousands of times per minute. Time-based clusters during cron jobs, backups, or traffic spikes tell me whether they’re caused by workloads or application routines. Using `INFO commandstats`, I get context on the number of calls and average durations, which I can conveniently access via the post INFO commandstats I delve deeper. I link the client names identified from the CLIENT LIST to services or microservices, thereby assigning responsibility and the Optimization plan specifically.
Optimization Strategies: Commands and Data Model
I replace expensive commands like KEYS on large data sets with SCAN using customized cursors to avoid deadlocks and improve Latency to reduce them. When Lua scripts take too long to run, I break the logic down into several smaller steps or use pre-aggregated data. Long execution times are often a symptom of the data model: I split very large lists, sets, or hashes, use additional indexes, or choose more appropriate data types. For recurring computationally expensive calculations, I cache results closer to the application and invalidate them in a controlled manner, rather than forcing them to be recalculated over and over again. I summarize typical misconfigurations and anti-patterns in a practical way via Typical misconfigurations together, so that I can correct avoidable mistakes more quickly and the Efficiency increase.
Client Context and Application Code
In the code, I reduce round trips through pipelining and bundling, which allows me to minimize the Server time While I don't change it, I do significantly reduce the latency experienced per call. Parameters from slow-log entries show me where unnecessary loops or repeated accesses occur. I ensure that clients assign meaningful names via CLIENT SETNAME so that the assignment is immediately clear to the team. I distribute write loads by identifying hot keys, diversifying access patterns, and reviewing TTL strategies. During migration phases or when setting feature flags, I specifically monitor the entries for affected paths to quickly identify any impacts and Quality to secure.
Resources, Topology, and Sources of Latency
Not all slowdowns are caused by inefficient commands, so I check for CPU spikes, memory bottlenecks, and network latency in parallel with the Entries in the slow log. An unfavorable shard distribution, too few replicas, or long cross-zone paths increase the perceived duration. I also check RDB/AOF settings and background jobs that temporarily put pressure on the server process. Under high load, I consider scaling options if the data model is already optimized and the command selection is correct. Only by correlating this with system metrics can I get a clear picture. Cause and Effect‑Chains are visible.
Integrate Slow Log into Monitoring
A dedicated dashboard shows me trends in log length, the number of slow commands per service, and related metrics such as CPU and memory usage. I integrate the slow-log data into existing observability pipelines, thereby creating a continuous Monitoring. In graphical user interfaces, I filter by commands, times, and clients to isolate anomalies more quickly. For practical workflows, I rely on tools with slow-log views, a workbench, and export functions, such as those found in the RedisInsight Guide describe. This significantly shortens the diagnostic process and increases the significance of the Metrics.
Practical Guide: Step-by-Step
First, I make sure that `slowlog-log-slower-than` and `slowlog-max-len` are set appropriately so that I neither generate noise nor miss relevant Signals lose. After that, I read the most recent data records, save them, and identify suspicious commands based on their frequency and duration. In the next step, I examine time windows, link CLIENT names, and look for patterns in recurring parameters. From this, I derive specific measures for the code, the data model, and caching strategies. Finally, I incorporate the analysis into my ongoing monitoring so that I can identify trends early and Regressions prevent.
Empirical Data and Tuning Criteria
A starting value of 10 ms as a threshold works well for many production environments, while lower values can be helpful in testing Details I adjust the log length so that it reflects typical daily or weekly patterns without wasting storage space. I establish a baseline, document typical command distributions, and watch for gradual changes. After deployments, I make a point of checking the slow log to detect early on whether new features are creating unwanted latency paths. This discipline provides reliable insights into when I should make adjustments and how I should Performance maintain it at a high level in the long term.
Limitations and Interpretation Guidelines for the Slow Log
I keep in mind that the Slow Log measures only the actual execution time in the server thread. Wait times in the command queue, TLS handshake overhead, or the time it takes to transmit large responses over the network do not appear there. Similarly, command arguments in the Slow Log are limited and may be truncated for memory reasons, which is why I consider parameters to be merely indicative rather than a complete picture. Because the log operates on a threshold-based system, I receive a sample of the slowest cases rather than a complete distribution. That’s why I supplement my analyses with latency percentiles from monitoring and, when necessary, use the built-in LATENCY monitor (threshold via `latency-monitor-threshold`) to detect sporadic spikes.
Cluster and Replication Considerations
In cluster setups, I check whether slow commands are concentrated on individual slots or shards. Cross-slot operations (e.g., MGET on keys without a hash tag) result in errors or detours and generate unnecessary round trips that are not visible in the slow log but increase perceived latency. Rebalancing, failover, and replication catch-ups affect system load: Commands such as WAIT may intentionally take longer until acknowledgments are received. Standby replicas have different access profiles; there, I examine slow log entries separately because read loads, sync overhead, and background processes differ from one another. For a thorough diagnosis, I export the slow log from each instance and correlate the timestamps across all nodes.
Persistence, Forks, and Memory Behavior
I keep an eye on RDB snapshots and AOF rewrites: When the Redis process forks, copy-on-write can lead to temporarily high memory usage and CPU spikes, which in turn can increase command execution times. AOF settings (e.g., appendfsync) affect write latencies; „everysec“ is usually a good compromise, while „always“ increases durability but can cause spikes. I also monitor active memory defragmentation, evictions, and the processing of expired keys. Large individual keys (e.g., hashes with tens of thousands of fields) cause noticeable pauses during expire cycles or deletions. I use `lazyfree` options (e.g., `lazyfree-lazy-eviction`) to offload the main thread by having the release of large structures performed asynchronously, provided the workload profile is suitable.
Blocking, Multi-Key, and Script Commands
I distinguish between commands with linear complexity (O(N)) and those with logarithmic or constant complexity. SORT, SUNIONSTORE, ZUNIONSTORE, or HGETALL operations on large structures frequently appear in the slow log. Although EVAL and EVALSHA are atomic and practical, they can tie up the server thread for a long time due to internal loops; smaller, well-tuned substeps are better here. Blocking commands such as BLPOP or XREAD BLOCK primarily block the client, not the server thread—but they become critical when combined with very large data structures. When scanning, I avoid broad MATCH patterns without index logic and calibrate COUNT so that I can keep the load under control; SCAN protects against complete deadlocks, but it is not a free pass for undirected searches.
Export, Automation, and Data Preparation
To ensure reproducible analyses, I regularly export the Slow Log and standardize the format. I include entries with client names, users (ACL), and service tags so that ownership is clearly identified. A simple shell workflow helps me with ad hoc exports:
# JSON-like export of the last 500 entries
redis-cli SLOWLOG GET 500 > slowlog.raw
# CSV example (ID;Timestamp;Duration (µs);Command;Client)
# Note: Arguments may be truncated in the slow log
redis-cli --raw SLOWLOG GET 200 | awk '
BEGIN{FS="\n"; OFS=";"}
/1\)/{id=$2} /2\)/{ts=$2} /3\)/{dur=$2} /4\)/{cmd=$0; gsub(/^[^"]*"/,"",cmd); gsub(/"[^$]*/,"",cmd)} /5\)/{client=$0}
/5\)/{print id,ts,dur,cmd,client}
' > slowlog.csv
In automation pipelines, I retrieve the data from all nodes, normalize timestamps (UTC), and calculate metrics per command, per client, and per time window. I make sure to export the data before every SLOWLOG RESET and adjust the rotation frequency to match the log length so that no peaks are lost.
Incident Response Best Practices
In acute cases, I first preserve the status quo: I check SLOWLOG LEN, export a generous number of the most recent entries, and temporarily increase slowlog-max-len so that no data is rotated out. Then I lower the threshold moderately to detect patterns that fall just below the previous threshold. At the same time, I monitor CPU usage, RSS memory, page faults, network RTT, and persistence events (RDB/AOF). If individual commands occur in large volumes, I temporarily reduce them using feature flags or tighter rate limits. For hot keys, I distribute accesses (key hashing/shard spread) and increase replication capacity as needed. Once the spike has subsided, I conduct an in-depth root cause analysis and implement permanent fixes in the code and data model.
Quality Assurance Before and After Deployments
Before releases, I significantly lower the slow-log threshold in staging to detect micro-inefficiencies early on. I define acceptable latency budgets (e.g., p95/p99 per command) and compare them to a documented baseline. After the rollout, I closely monitor slow-log entries for the affected services; any deviations lead to a quick rollback or targeted optimizations. A canary rollout per shard/zone helps me observe effects in isolation. Communication is key: Each client sets a descriptive name so that I can immediately assign slow-log entries to an owner—this speeds up problem-solving enormously.
Decision Logic for Threshold and Log Length
I set the threshold not only as an absolute value, but also based on context: On very fast nodes with NVMe and ample CPU resources, I tend to lower it to 5–8 ms during production hours to detect subtle hotspots; with low-cost hardware or heavy burst traffic, I take a more conservative approach to ensure the log remains signal-rich. I scale the log length based on the command rate and the export interval: The higher the command frequency, the larger the window (e.g., 2048–4096), so that I capture entire traffic cycles. During load tests, I intentionally set the length high and schedule exports promptly so as not to miss any spikes. During quiet periods, I lower the values to conserve memory and keep the analysis focused.
Common Patterns in Practice
Typically, I see three categories of causes: First, expensive O(N) operations on large structures (SORT, large set/hash unions, full iterations); second, side effects of the system (forks, defragmentation, evictions), and third, application patterns (N+1 lookups, redundant calculations, lack of caching). Countermeasures follow directly from this: replacing instructions and limiting the data volume, decoupling heavy operations into jobs/queues, asynchronous release of large objects, clean TTL and invalidation strategies, and more aggregation close to the consumer. I always link these measures to metrics so that successes are measurable and regressions are quickly visible.
Compact summary
I use the Slow Log to track the pure Server time I make expensive commands visible, set appropriate thresholds, and protect data records from resets. Using configurations via redis.conf or CONFIG SET, I keep the diagnostic period flexible without consuming unnecessary memory. From the entries, I identify patterns in commands, times, and clients, and then optimize command selection, the data model, caching, and application code. At the same time, I correlate slow-log statistics with system metrics and APM signals so that I can clearly pinpoint the root causes. This ensures that the Performance It becomes predictable, and latency issues lose their element of surprise.
