Redis高負載排查記錄

Redis簡單運維學習

---

週一早上剛上班，忽然大量用戶反饋進入網頁很慢，登陸服務器一看，Redis調用時間嚴重超時，這樣高速的緩存反而變成了短板，因爲數據一直沒有返回，致使了請求響應變慢。

網頁監控

經過阿里的 Grafana 監控，服務器的 CPU 負載、內存、網絡輸入輸出都挺正常的，因此確定是 Redis 出現了問題。

咱們應用使用的是單節點的 32M 16GB 的阿里雲 Redis，登陸網頁監控看性能監控，發現 CPU 使用狀況飆升到100%！！！

QPS 雖然從 1000 多升到 6000，可是遠遠低於極限值，鏈接數量從 0 升到 3000，也是遠遠低於極限值（可能用戶剛上班，開始有請求，而後響應延遲，致使命令隊列數量過多，打開不少鏈接）。

臨時方案：先租用一臺新的 Redis 服務器，更換應用服務器的 Redis 配置，重啓應用，避免影響更多用戶。

而後咱們繼續跟蹤 Redis 的具體狀況。

---

服務器命令監控

登陸 Redis-cli，經過 info 命令查看服務器狀態和命令統計，祥哥總結了兩點異常點：

• 查詢 redis 慢指令 slowlog，排行前十的指令均爲'keys *'，而且耗時嚴重，在當前業務流量下執行'keys *'，必定會阻塞業務，致使查詢慢，cpu 高的。值得注意的是應用層面沒有開放 'keys *' 接口，不排查有後臺人爲或後臺程序觸發該指令。

• 查看 redis 指令執行狀況，排除 'exec','flushall' 等指令，業務使用指令中，耗時嚴重的有 setnx 有7.5千萬次調用平均耗時 6s，setex 有8.4千萬次調用平均耗時7.33s，del 有2.6億次調用平均耗時69s，hmset 有1億次調用平均耗時 64s，hmget 有6.8千萬次調用平均耗時 9s，hgetall 有14億次調用平均耗時 205s，keys 有2千萬次調用平均耗時 3740s。 一般而言，這些指令耗時與 value 大小呈正比，因此能夠排查這些指令相關的數據近期有沒有較大增加。或者近期有沒有業務改造，會頻繁使用上述指令，也會形成 cpu 高。

（當時忘了截圖，下圖只是展現命令和參數含義）

經過 info commandstats 能夠查看 Redis 命令統計信息，其中命令格式是

cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX
調用次數、耗費CPU時間、每一個命令平均耗費CPU(單位爲微秒）
複製代碼

經過 slowlog 命令查看慢命令（默認超過 10ms 就會被記錄到日誌，只會記錄其命令執行的時間，不包含 IO 往返操做，也不記錄單由網絡延遲引發的響應慢）

(當時也忘了截圖，因此就介紹一下 slowlog 怎麼看）

xxxxx> slowlog get 10
 3) 1) (integer) 411           
    2) (integer) 1545386469     
    3) (integer) 232663          
    4) 1) "keys"              
       2) "mecury:*"
複製代碼

圖中各字段表示的是：

• 1=日誌的惟一標識符
• 2=命令的執行時間點，以UNIX時間戳表示
• 3=查詢命令執行時間，以微妙爲單位，🌰中的是230ms
• 4=執行的命令，以數組的形式排列。完整的命令是 keys mucury:*

因此經過這些參數，基本能夠肯定，是忽然有大量的keys *命令致使CPU負載升高，致使響應延遲，問題咱們應用中沒有開放keys *命令Σ(oﾟдﾟoﾉ)

*最後將這些統計結果和慢命令發到研發羣，發現是別的應用配置配成了咱們的Redis，而後他們有個業務場景是爬數據，忽然涌入大量的調用，不斷的keys ，致使咱們的Redis不堪重負，因而將配置修改正確，再也不調用咱們的Redis。

---

總結

• Redis 抖動能夠先看網頁監控（阿里雲作的真好！）
• 經過命令查看 Redis 指令狀態和慢命令的狀況
• 考慮優化 Redis 在代碼中的使用狀況
• 若是流量繼續上升，須要考慮一下升級了=-=

---

參考文章

1. Redis性能問題排查解決手冊(七)
2. redis info command