Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This section discusses troubleshooting issues caused by conditions on an Azure Managed Redis (preview) server or any of the virtual machines hosting it.
Note
Several of the troubleshooting steps in this guide include instructions to run Redis commands and monitor various performance metrics. For more information and instructions, see the articles in the Additional information section.
High CPU means the Redis server is busy and unable to keep up with requests, leading to timeouts. Check the CPU metric on your cache by selecting Monitoring from the Resource menu on the left. You see the CPU graph in the working pane under Insights. Or, add a metric set to CPU under Metrics.
Following are some options to consider for high CPU.
For higher performance, consider scaling up to a larger cache size with more CPU cores. For more information, see Performance tiers.
For more information, see Avoid client connection spikes.
For more information, see Long running commands.
Scaling operations are CPU and memory intensive as it could involve moving data around nodes and changing cluster topology. For more information, see Scaling.
If your Azure Managed Redis underwent a failover, all client connections from the node that went down are transferred to the node that is still running. The CPU could spike because of the increased connections. You can try rebooting your client applications so that all the client connections get recreated and redistributed among the two nodes.
Memory pressure on the server can lead to various performance problems that delay processing of requests. When memory pressure hits, the system pages data to disk, which causes the system to slow down significantly.
Here are some possible causes of memory pressure:
- The cache is filled with data near its maximum capacity
- Redis server is seeing high memory fragmentation
Fragmentation is likely to be caused when a load pattern is storing data with high variation in size. For example, fragmentation might happen when data is spread across 1 KB and 1 MB in size. When a 1-KB key is deleted from existing memory, a 1-MB key can’t fit into it causing fragmentation. Similarly, if 1-MB key is deleted and 1.5-MB key is added, it can’t fit into the existing reclaimed memory. This causes unused free memory and results in more fragmentation.
If the used_memory_rss value is higher than 1.5 times the used_memory metric, there's fragmentation in memory. The fragmentation can cause issues when:
- Memory usage is close to the max memory limit for the cache, or
UsedMemory_RSSis higher than the Max Memory limit, potentially resulting in page faulting in memory.
If a cache is fragmented and is running under high memory pressure, the system does a failover to try recovering Resident Set Size (RSS) memory.
Redis exposes two stats, used_memory and used_memory_rss, through the INFO command that can help you identify this issue. You can view these metrics using the portal.
There are several possible changes you can make to help keep memory usage healthy:
- Configure a memory policy and set expiration times on your keys. This policy may not be sufficient if you have fragmentation.
- Create alerts on metrics like used memory to be notified early about potential impacts.
- Scale to a larger cache size with more memory capacity. For more information, see Azure Managed Redis planning FAQs.
For recommendations on memory management, see Best practices for memory management.
For more information, see Long running commands.
For more information, see Network bandwidth limitation.