來源:https://www.sevenyuan.cn/
網(wǎng)頁監(jiān)控
通過阿里的 Grafana 監(jiān)控,服務器的 CPU 負載、內存、網(wǎng)絡輸入輸出都挺正常的,所以肯定是 Redis 出現(xiàn)了問題。
我們應用使用的是單節(jié)點的 32M 16GB 的阿里云 Redis,登錄網(wǎng)頁監(jiān)控看性能監(jiān)控,發(fā)現(xiàn) CPU 使用情況飆升到100%?。。?/span>
QPS 雖然從 1000 多升到 6000,但是遠遠低于極限值,連接數(shù)量從 0 升到 3000,也是遠遠低于極限值(可能用戶剛上班,開始有請求,然后響應延遲,導致命令隊列數(shù)量過多,打開很多連接)。
臨時方案:先租用一臺新的 Redis 服務器,更換應用服務器的 Redis 配置,重啟應用,避免影響更多用戶。
然后我們繼續(xù)跟蹤 Redis 的具體情況。
服務器命令監(jiān)控
登錄 Redis-cli,通過 info 命令查看服務器狀態(tài)和命令統(tǒng)計,祥哥總結了兩點異常點:
查詢 redis 慢指令 slowlog,排行前十的指令均為keys *,并且耗時嚴重,在當前業(yè)務流量下執(zhí)行keys*,一定會阻塞業(yè)務,導致查詢慢,cpu 高的。值得注意的是應用層面沒有開放keys *接口,不排查有后臺人為或后臺程序觸發(fā)該指令。
查看 redis 指令執(zhí)行情況,排除exec,flushall等指令,業(yè)務使用指令中,耗時嚴重的有 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 大小呈正比,所以可以排查這些指令相關的數(shù)據(jù)近期有沒有較大增長?;蛘呓谟袥]有業(yè)務改造,會頻繁使用上述指令,也會造成 cpu 高。
通過 info commandstats 可以查看 Redis 命令統(tǒng)計信息,其中命令格式是
cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX 調用次數(shù)、耗費CPU時間、每個命令平均耗費CPU(單位為微秒)
通過 slowlog 命令查看慢命令(默認超過 10ms 就會被記錄到日志,只會記錄其命令執(zhí)行的時間,不包含 IO 往返操作,也不記錄單由網(wǎng)絡延遲引起的響應慢)
(當時也忘了截圖,所以就介紹一下 slowlog 怎么看)
xxxxx> slowlog get 10 3) 1) (integer) 411 2) (integer) 1545386469 3) (integer) 232663 4) 1) "keys" 2) "mecury:*"
圖中各字段表示的是:
- 1=日志的唯一標識符
- 2=命令的執(zhí)行時間點,以UNIX時間戳表示
- 3=查詢命令執(zhí)行時間,以微妙為單位,中的是230ms
- 4=執(zhí)行的命令,以數(shù)組的形式排列。完整的命令是 keys mucury:*
所以通過這些參數(shù),基本可以確定,是突然有大量的keys *命令導致CPU負載升高,導致響應延遲,問題我們應用中沒有開放keys *命令Σ(o?д?o?)
最后將這些統(tǒng)計結果和慢命令發(fā)到研發(fā)群,發(fā)現(xiàn)是別的應用配置配成了我們的Redis,然后他們有個業(yè)務場景是爬數(shù)據(jù),突然涌入大量的調用,不斷的keys *,導致我們的Redis不堪重負,于是將配置修改正確,不再調用我們的Redis。
總結
- Redis 抖動可以先看網(wǎng)頁監(jiān)控(阿里云做的真好?。?/span>
- 通過命令查看 Redis 指令狀態(tài)和慢命令的情況
- 考慮優(yōu)化 Redis 在代碼中的使用情況
- 如果流量繼續(xù)上升,需要考慮一下升級了=-=
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!