You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-best-practices-development.md
+6-6Lines changed: 6 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -39,13 +39,13 @@ This request/response is a difficult one to measure. You could instrument your c
39
39
Resolutions for large response sizes are varied but include:
40
40
41
41
- Optimize your application for a large number of small values, rather than a few large values.
42
-
- The preferred solution is to break up your data into related smaller values.
43
-
- See the post [What is the ideal value size range for redis? Is 100 KB too large?](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ) for details on why smaller values are recommended.
42
+
- The preferred solution is to break up your data into related smaller values.
43
+
- See the post [What is the ideal value size range for redis? Is 100 KB too large?](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ) for details on why smaller values are recommended.
44
44
- Increase the size of your VM to get higher bandwidth capabilities
45
-
- More bandwidth on your client or server VM may reduce data transfer times for larger responses.
46
-
- Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client may not be enough.
45
+
- More bandwidth on your client or server VM may reduce data transfer times for larger responses.
46
+
- Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client may not be enough.
47
47
- Increase the number of connection objects your application uses.
48
-
- Use a round-robin approach to make requests over different connection objects.
48
+
- Use a round-robin approach to make requests over different connection objects.
49
49
50
50
## Key distribution
51
51
@@ -57,7 +57,7 @@ Try to choose a Redis client that supports [Redis pipelining](https://redis.io/t
57
57
58
58
## Avoid expensive operations
59
59
60
-
Some Redis operations, like the [KEYS](https://redis.io/commands/keys) command, are expensive and should be avoided. For some considerations around long running commands, see [long-running commands](cache-troubleshoot-server.md#long-running-commands)
60
+
Some Redis operations, like the [KEYS](https://redis.io/commands/keys) command, are expensive and should be avoided. For some considerations around long running commands, see [long-running commands](cache-troubleshoot-timeouts.md#long-running-commands).
Copy file name to clipboardExpand all lines: articles/azure-cache-for-redis/cache-monitor-troubleshoot-faq.yml
+13-3Lines changed: 13 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
1
### YamlMime:FAQ
2
2
metadata:
3
-
title: Azure Cache for Redis monitoring and troubleshooting FAQs
4
-
description: Learn the answers to common questions that help you monitor and troubleshoot Azure Cache for Redis
3
+
title: Azure Cache for Redis common error FAQs
4
+
description: Learn the answers to common questions that help you monitor and troubleshoot Azure Cache for Redis.
5
5
author: flang-msft
6
6
ms.author: franlanglois
7
7
ms.service: cache
8
8
ms.topic: conceptual
9
-
ms.date: 08/06/2020
9
+
ms.date: 12/01/2021
10
10
11
11
title: Azure Cache for Redis monitoring and troubleshooting FAQs
12
12
summary: This article provides answers to common questions about how to monitor and troubleshoot Azure Cache for Redis.
@@ -49,6 +49,16 @@ sections:
49
49
* Server-side causes
50
50
* On the standard cache offering, the Azure Cache for Redis service started a fail-over from the primary node to the replica node.
51
51
* Azure was patching the instance where the cache was deployed during a Redis server update or general VM maintenance.
52
+
53
+
- question: |
54
+
Why am I seeing "Cache is busy processing a previous update request or is undergoing system maintenance. As such, it is currently unable to accept the update request. Please try again later."
55
+
answer: |
56
+
This message indicates that a management operation, like scaling or patching, is in progress on your cache. All other management operations are blocked until the ongoing operation is completed. During this time, you can expect your Azure Cache For Redis to be fully functional for client operations.
57
+
- question: |
58
+
Why is my cache in "Failed" state?
59
+
answer: |
60
+
Azure Cache For Redis can end up in a *Failed* state if a management operation fails. Despite this state, you can expect your Azure Cache For Redis to be fully functional for client operations.
title: Troubleshoot Azure Cache for Redis client-side issues
3
-
description: Learn how to resolve common client-side issues with Azure Cache for Redis such as Redis client memory pressure, traffic burst, high CPU, limited bandwidth, large requests or large response size.
2
+
title: Troubleshoot Azure Cache for Redis client issues
3
+
description: Learn how to resolve common client issues, such as client memory pressure, traffic burst, high CPU, limited bandwidth, large requests, or large response size, when using Azure Cache for Redis.
4
4
author: flang-msft
5
5
ms.author: franlanglois
6
6
ms.service: cache
7
7
ms.topic: troubleshooting
8
-
ms.date: 10/18/2019
8
+
ms.date: 12/31/2021
9
9
---
10
10
# Troubleshoot Azure Cache for Redis client-side issues
11
11
@@ -15,11 +15,10 @@ This section discusses troubleshooting issues that occur because of a condition
<!-- [Large request or response size](#large-request-or-response-size) -->
19
18
20
19
## Memory pressure on Redis client
21
20
22
-
Memory pressure on the client machine leads to all kinds of performance problems that can delay processing of responses from the cache. When memory pressure hits, the system may page data to disk. This _page faulting_ causes the system to slow down significantly.
21
+
Memory pressure on the client can lead to performance problems that can delay processing of responses from the cache. When memory pressure hits, the system might page data to disk. This _page faulting_ causes the system to slow down significantly.
23
22
24
23
To detect memory pressure on the client:
25
24
@@ -33,85 +32,28 @@ High memory pressure on the client can be mitigated several ways:
33
32
34
33
## Traffic burst
35
34
36
-
Bursts of traffic combined with poor `ThreadPool` settings can result in delays in processing data already sent by the Redis Server but not yet consumed on the client side.
37
-
38
-
Monitor how your `ThreadPool` statistics change over time using [an example `ThreadPoolLogger`](https://github.com/JonCole/SampleCode/blob/master/ThreadPoolMonitor/ThreadPoolLogger.cs). You can use `TimeoutException` messages from StackExchange.Redis like below to further investigate:
In the preceding exception, there are several issues that are interesting:
46
-
47
-
- Notice that in the `IOCP` section and the `WORKER` section you have a `Busy` value that is greater than the `Min` value. This difference means your `ThreadPool` settings need adjusting.
48
-
- You can also see `in: 64221`. This value indicates that 64,211 bytes have been received at the client's kernel socket layer but haven't been read by the application. This difference typically means that your application (for example, StackExchange.Redis) isn't reading data from the network as quickly as the server is sending it to you.
49
-
50
-
You can [configure your `ThreadPool` Settings](cache-management-faq.yml#important-details-about-threadpool-growth) to make sure that your thread pool scales up quickly under burst scenarios.
35
+
This section was moved. For more information, see [Traffic burst and thread pool configuration](cache-troubleshoot-timeouts.md#traffic-burst-and-thread-pool-configuration).
51
36
52
37
## High client CPU usage
53
38
54
-
High client CPU usage indicates the system can't keep up with the work it's been asked to do. Even though the cache sent the response quickly, the client may fail to process the response in a timely fashion.
55
-
56
-
Monitor the client's system-wide CPU usage using metrics available in the Azure portal or through performance counters on the machine. Be careful not to monitor *process* CPU because a single process can have low CPU usage but the system-wide CPU can be high. Watch for spikes in CPU usage that correspond with timeouts. High CPU may also cause high `in: XXX` values in `TimeoutException` error messages as described in the [Traffic burst](#traffic-burst) section.
57
-
58
-
> [!NOTE]
59
-
> StackExchange.Redis 1.1.603 and later includes the `local-cpu` metric in `TimeoutException` error messages. Ensure you using the latest version of the [StackExchange.Redis NuGet package](https://www.nuget.org/packages/StackExchange.Redis/). There are bugs constantly being fixed in the code to make it more robust to timeouts so having the latest version is important.
60
-
>
61
-
62
-
To mitigate a client's high CPU usage:
63
-
64
-
- Investigate what is causing CPU spikes.
65
-
- Upgrade your client to a larger VM size with more CPU capacity.
39
+
This section was moved. For more information, see [High CPU on client hosts](cache-troubleshoot-timeouts.md#high-cpu-on-client-hosts).
66
40
67
41
## Client-side bandwidth limitation
68
42
69
-
Depending on the architecture of client machines, they may have limitations on how much network bandwidth they have available. If the client exceeds the available bandwidth by overloading network capacity, then data isn't processed on the client side as quickly as the server is sending it. This situation can lead to timeouts.
70
-
71
-
Monitor how your Bandwidth usage change over time using [an example `BandwidthLogger`](https://github.com/JonCole/SampleCode/blob/master/BandWidthMonitor/BandwidthLogger.cs). This code may not run successfully in some environments with restricted permissions (like Azure web sites).
43
+
This section was moved. For more information, see [Network bandwidth limitation on client hosts](cache-troubleshoot-timeouts.md#network-bandwidth-limitation-on-client-hosts).
72
44
73
-
To mitigate, reduce network bandwidth consumption or increase the client VM size to one with more network capacity.
74
-
75
-
<!--
76
-
## Large request or response Size
77
-
78
-
A large request/response can cause timeouts. As an example, suppose your timeout value configured on your client is 1 second. Your application requests two keys (for example, 'A' and 'B') at the same time (using the same physical network connection). Most clients support request "pipelining", where both requests 'A' and 'B' are sent one after the other without waiting for their responses. The server sends the responses back in the same order. If response 'A' is large, it can eat up most of the timeout for later requests.
79
-
80
-
In the following example, request 'A' and 'B' are sent quickly to the server. The server starts sending responses 'A' and 'B' quickly. Because of data transfer times, response 'B' must wait behind response 'A' times out even though the server responded quickly.
81
-
82
-
```console
83
-
|-------- 1 Second Timeout (A)----------|
84
-
|-Request A-|
85
-
|-------- 1 Second Timeout (B) ----------|
86
-
|-Request B-|
87
-
|- Read Response A --------|
88
-
|- Read Response B-| (**TIMEOUT**)
89
-
```
90
-
91
-
This request/response is a difficult one to measure. You could instrument your client code to track large requests and responses.
92
-
93
-
Resolutions for large response sizes are varied but include:
94
-
95
-
1. Optimize your application for a large number of small values, rather than a few large values.
96
-
- The preferred solution is to break up your data into related smaller values.
97
-
- See the post [What is the ideal value size range for redis? Is 100 KB too large?](https://groups.google.com/forum/#!searchin/redis-db/size/redis-db/n7aa2A4DZDs/3OeEPHSQBAAJ) for details on why smaller values are recommended.
98
-
1. Increase the size of your VM to get higher bandwidth capabilities
99
-
- More bandwidth on your client or server VM may reduce data transfer times for larger responses.
100
-
- Compare your current network usage on both machines to the limits of your current VM size. More bandwidth on only the server or only on the client may not be enough.
101
-
1. Increase the number of connection objects your application uses.
102
-
- Use a round-robin approach to make requests over different connection objects.
103
-
104
-
-->
105
-
106
45
## High client connections
107
46
108
-
Client connections reaching the maximum for the cachecan cause failures in client requests for connections beyond the maximum, and can also cause high server CPU usage on the cache due to processing repeated reconnection attempts.
47
+
When client connections reach the maximum for the cache, you can have failures in client requests for connections beyond the maximum. High client connections can also cause high server load when processing repeated reconnection attempts.
109
48
110
-
High client connections may indicate a connection leak in client code. Connections may not be getting re-used or closed properly. Review client code for connection use.
49
+
High client connections might indicate a connection leak in client code. Connections might not be getting reused or closed properly. Review client code for connection use.
111
50
112
-
If the high connections are all legitimate and required client connections, upgrading your cache to a size with a higher connection limit may be required.
51
+
If the high connections are all legitimate and required client connections, upgrading your cache to a size with a higher connection limit might be required. Check if the `Max aggregate for Connected Clients` metric is close or higher than the maximum number of allowed connections for a particular cache size. For more information on sizing per client connections, see [Azure Cache for Redis performance](cache-planning-faq.yml#azure-cache-for-redis-performance).
113
52
114
53
## Additional information
115
54
116
-
-[Troubleshoot Azure Cache for Redis server-side issues](cache-troubleshoot-server.md)
55
+
These articles provide more information on troubleshooting and performance testing:
56
+
57
+
-[Troubleshoot Azure Cache for Redis server issues](cache-troubleshoot-server.md)
58
+
-[Troubleshoot Azure Cache for Redis latency and timeouts](cache-troubleshoot-timeouts.md)
117
59
-[How can I benchmark and test the performance of my cache?](cache-management-faq.yml#how-can-i-benchmark-and-test-the-performance-of-my-cache-)
0 commit comments