溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章給大家分享的是有關Redis超時排查的示例分析的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。
前兩天的工作中，突然收到告警，提示 Redis 掛了，同時大群也在說某某 Redis 連接超時了。當初以為是有大問題，誰知道它過了一會兒就恢復了。那個時候，我登上服務器，查看監控。第一時間看看 QPS：
可以看到 QPS 并不高，但是中間有段時間沒取到數據是怎么回事？那么繼續看看 Redis 的 cpu 使用率：
可以看到 cpu 已經飽和，這也就能解釋為何斷圖了，因為 redis 是單線程，在使用 cpu 100% 以后，就無法處理其他的命令了，zabbix 也就無法執行 info 命令取 qps 了。那么已經知道是 cpu 使用飽和造成的問題，那么到底是什么原因呢？那么繼續查看，cpu 使用高的這段時間有沒有慢日志：
好像也不是導致 cpu 高的兇手，這就難排查了，這個實例是 1 主 1 從。那么我看看從庫的 cpu 使用情況看看：
臥槽，怎么回事，從庫沒有使用的怎么 cpu 也用到了 74%？這不科學啊？管他的，看看從庫有沒有慢日志：
臥槽，怎么回事？從庫沒人使用啊。看看是否只讀：
127.0.0.1:6103> CONFIG GET "slave-read-only"
1) "slave-read-only"
2) "yes"
127.0.0.1:6103>
看來是只讀的，這把我給整懵了。最后突然想到是主庫在這個點有 big key 過期，而主庫過期 key 操作慢是不會記錄慢日志的，從庫的 key 過期是由主庫發起 DEL 指令刪除的。這時從庫就會記錄慢日志，從上面慢日志可以看到這些 DEL 操作最大的 335ms，怪不得會有應用連接超時的。
再使用命令 info commandstats 看看：
感謝各位的閱讀！關于“Redis超時排查的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
