Advanced troubleshooting with Redis commands

  • Gilt für:: ✅ Azure Managed Redis

Azure Managed Redis supports many built-in Redis commands that help you monitor performance, diagnose issues, and understand your cache's behavior. You can run these commands from the Console blade in the Azure portal or from any Redis client connected to your cache.

This article covers the most commonly used diagnostic commands and explains how they behave on Azure Managed Redis.

SLOWLOG

The Redis slow log records commands whose execution time exceeds a configurable threshold. Use it to find expensive commands that might be causing latency or timeout issues.

The execution time measures only the time the Redis engine spends processing the command. It doesn't include network I/O, client communication, or time spent waiting in the queue.

How SLOWLOG works on Azure Managed Redis

Azure Managed Redis uses Redis Enterprise, which routes all client traffic through a proxy layer. The behavior of SLOWLOG depends on the clustering policy configured on your cache:

  • Enterprise Cluster Policy: The proxy automatically fans out SLOWLOG GET, SLOWLOG LEN, and SLOWLOG RESET to all primary shards and returns merged results as a single unified list. You get a cluster-wide view of slow commands without needing to query individual shards.
  • OSS Cluster Policy: Each node has its own endpoint, and SLOWLOG returns entries from the shards local to that node only. In OSS Cluster mode, your Redis client library automatically routes commands to the correct node based on key hash slots. To collect a complete view of slow commands across the entire cache, your client library must query each node. Most Redis client libraries support this through cluster-aware commands.

SLOWLOG commands

Command Description
SLOWLOG GET [count] Retrieve the most recent slow command entries. The optional count limits the number of entries returned.
SLOWLOG LEN Return the number of entries currently in the slow log.
SLOWLOG RESET Clear all entries from the slow log.

Configure SLOWLOG

Two configuration parameters control SLOWLOG behavior:

Parameter Description Default
slowlog-log-slower-than Threshold in microseconds. Commands that exceed this value are logged. Set to 0 to log every command. Set to -1 to disable. 10,000 (10 ms)
slowlog-max-len Maximum number of entries stored per shard. When the log is full, the oldest entry is removed. 128

To view or change these settings:

CONFIG GET slowlog-log-slower-than
CONFIG SET slowlog-log-slower-than 5000
CONFIG GET slowlog-max-len
CONFIG SET slowlog-max-len 256

Note

The slowlog-max-len setting applies per shard. On a cache with the Enterprise Cluster policy, SLOWLOG GET returns merged results from all primary shards, so the total number of entries returned can be up to slowlog-max-len multiplied by the number of primary shards. The maximum allowed value for slowlog-max-len is 1,024.

Interpret SLOWLOG results

  • Execution time is shard processing time only. It doesn't include network latency, proxy overhead, or time spent waiting in the command queue.
  • Entry IDs might not be sequential across restarts. During a failover or shard restart, the entry ID counter resets. Use the combination of timestamp, execution time, and command to identify unique entries instead.
  • Internal cluster traffic. At low thresholds (below 1,000 microseconds), you might see internal cluster management commands such as INFO and PING. These commands are normal and can be ignored.

Common expensive commands

Command Time complexity Recommendation
KEYS * O(N) Replace with SCAN to iterate incrementally.
SORT O(N+M*log(M)) Avoid on large collections, or use LIMIT and BY clauses.
LRANGE on large lists O(S+N) Paginate with small ranges.
SMEMBERS on large sets O(N) Use SSCAN to iterate incrementally.
HGETALL on large hashes O(N) Use HSCAN or HMGET for specific fields.
ZRANGEBYSCORE on large sorted sets O(log(N)+M) Use LIMIT to restrict result size.

For the full SLOWLOG command reference, see SLOWLOG GET in the Redis documentation.

INFO

The INFO command returns information and statistics about the Redis server in a format that's easy to read and parse. It covers memory usage, CPU consumption, replication status, keyspace statistics, and more.

INFO [section]

Commonly used sections:

Section Description
INFO memory Memory usage, fragmentation ratio, and allocator statistics.
INFO cpu CPU time consumed by the Redis process.
INFO stats General statistics such as total connections received, commands processed, and keyspace hits/misses.
INFO replication Replication status, including whether the instance is a primary or replica and replication offset.
INFO keyspace Database-level key count and expiration statistics.
INFO clients Connected client count and blocked client count.
INFO server Redis version, uptime, and configuration details.

Note

On Azure Managed Redis with the Enterprise Cluster policy, INFO returns aggregated information from the node you're connected to. With the OSS Cluster policy, each node endpoint returns its own local information.

For the full command reference, see INFO in the Redis documentation.

MONITOR

The MONITOR command streams every command that the Redis server processes in real time. This command is useful for debugging because you can see exactly what commands your application sends.

MONITOR

Warning

MONITOR is resource-intensive and can degrade cache performance. Use it only for short debugging sessions in nonproduction environments. Don't leave MONITOR running in production.

For the full command reference, see MONITOR in the Redis documentation.

Command statistics

The INFO commandstats section provides per-command execution statistics, including the number of calls, total execution time, and average execution time for each command type.

INFO commandstats

Use command statistics to:

  • Find which command types consume the most total execution time.
  • Identify infrequently called but expensive commands.
  • Establish a baseline of normal command patterns for your workload.

For more details, see the commandstats section under INFO in the Redis documentation.

  1. Check the Cache Latency metric. In the Azure portal, open your cache and select Monitoring > Metrics. Add the Cache Latency (Microseconds) metric. If you see sustained high values, proceed to the next step.

  2. Review the slow log.

    SLOWLOG GET 25

    Look for commands with high execution times or commands that appear frequently.

  3. Check command statistics. Run INFO commandstats to see which command types consume the most time across your workload.

  4. Lower the SLOWLOG threshold if needed. If the slow log is empty but latency is high, temporarily lower the threshold:

    CONFIG SET slowlog-log-slower-than 1000

  5. Identify and optimize. Common patterns include:

    • A single command type dominating the log — optimize or replace the command.
    • Commands on specific large keys — consider breaking up large data structures.
    • Burst of entries at the same timestamp — indicates a blocking command that queued other commands behind it.

  6. Reset and monitor. After making changes, clear the slow log and check again:

    SLOWLOG RESET

  7. Restore defaults. After diagnosis, restore the default SLOWLOG threshold:

    CONFIG SET slowlog-log-slower-than 10000

Related content

  • Last updated on