Azure Redis在使用的過程當中,屢次無規律的出現超時問題。抓取到客戶端的異常錯誤後,想進一步的分析是何緣由致使了以下異常呢?redis
Timeout awaiting response (outbound=0KiB, inbound=0KiB, 5984ms elapsed, timeout is 5000ms), command=GET,
next: GET n:AbpZeroMultiTenantLocalizationDictionaryCache,c:HMedia#zh-CN#0,
inst: 0, qu: 0, qs: 498, aw: False, rs: ReadAsync, ws: Idle, in: 65536,
serverEndpoint: xxxxxx-cache.redis.cache.chinacloudapi.cn:6380,
mc: 1/1/0, mgr: 10 of 10 available, clientName: RD0003FF04A4F7,
IOCP: (Busy=70,Free=930,Min=250,Max=1000),
WORKER: (Busy=430,Free=32337,Min=400,Max=32767), v: 2.1.58.34321
官方文檔對該類問題的解釋爲:api
雖然這裏Busy大於Min的Worker數量,表示目前客戶端中所設置的ThreadPool值不夠用,須要作必定的調整。可是這並非Redis出現持續超時的根本緣由,仍是須要繼續排查是否有某一方面達到了性能的限制呢?緩存
根據以上的四步原則。查看Azure Redis的指標,發現網絡的讀寫出現尖峯。指標圖相似於:服務器
Cache Read
計數器來建立警報。可是,只查看主節點的流量(注:Azure Redis有兩個節點,一主一從),寫入流量(409KB)與上圖中的38.07MB卻存在巨大的差異, 難到這是有鏈接直接操做從節點,而不經過主節點?網絡
1)在Azure Redis的門戶中,打開Metrics頁面, 選取name space爲Redis Cache standard metrics工具
2)Metric 選取Cache Write (Instance Based)性能
3)添加Filter,Primary = Falsespa
4)啓用Apply Splitting,按照端口細分命令行
這個時候,就須要跟進一步的分析,是那些客戶端鏈接到Redis?它們執行命令的次數有多少呢?它們執行了那些命令呢?3d
能夠經過Redis-cli.exe工具鏈接到Redis後,經過 client list 當前的客戶端鏈接狀況和IP地址,已經經過numops查看當前鏈接已經執行的OPS。而後經過 monitor 指令實時監控命令的執行和所發出請求的IP地址
1) 使用 redis-cli.exe鏈接到Azure Redis服務
redis-cli.exe -h yourcachename.redis.cache.chinacloudapi.cn -p 6379 -a YourAccessKey
2) 使用 client list 查看你鏈接數和 numops數 (實時)
3) 使用monitor指令監控所執行的命令(實時)
[完]
排查 Azure Cache for Redis 超時問題:https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-troubleshoot-timeouts
將 Redis 命令行工具與 Azure Redis 緩存配合使用:https://docs.azure.cn/zh-cn/azure-cache-for-redis/cache-how-to-redis-cli-tool#connect-using-the-redis-command-line-tool
Azure數據中心各資源的IP地址列表:https://www.microsoft.com/en-us/download/details.aspx?id=57062
Redis Private Endpoint:https://docs.microsoft.com/zh-cn/azure/azure-cache-for-redis/cache-private-link
Redis部署至VNET:https://docs.microsoft.com/zh-cn/azure/azure-cache-for-redis/cache-how-to-premium-vnet