故障分析 ｜ bgsave 導致 redis 定期卡頓案例一則

1、故障分析| bgsave導致redis定 期卡頓案例一那么1、背景線上有套redis主從，版本4.0,開發(fā)抱怨說經(jīng)常會出現(xiàn)周期性卡 頓。應(yīng)用日志顯示每隔10多分鐘出現(xiàn)一次，一個普通調(diào)用就需要執(zhí)行1s 左右，然后自動恢復，get/set均受影響ts econtent 今2022-03-11 09:34:222022-03-11 09:3422278 -nio-5151 -exec-9 INFOr- redis se| use: 1047ms2022-03-11 09:34:222022-03-11 09:34:22277 -nio-5151-exec-5 (INFO) redi use: 110

2、5ms2022-03-11 09:34:222022-03-11 09:34:22277 -nio-5151-exec-2 (INFO 廠 redis se| use: 217ms2、診斷查看redis qps和epu監(jiān)控，均未發(fā)現(xiàn)有用線索。登錄redis查看slowlog ,也沒有吻合時間點的慢查詢。evicted_keys指標一直是0 , expired_keys數(shù)量雖然很多，但是 一直沒有明顯波動，不太可能是驅(qū)逐過期鍵導致。經(jīng)組里同事提醒注意到latest_fork_usec指標，執(zhí)行一次接近1s 左右，大約每15分鐘觸發(fā)一次bgsave ,和應(yīng)用出現(xiàn)慢查詢的頻率大致 吻合，現(xiàn)在初步認定

3、是redis實例定期bgsave導致的應(yīng)用卡頓。在相當長的一段時間內(nèi)，我一直認為redis的bgsave衍生出1個 子進程并旦采用copy-on- write機制，不會對redis本身有太多影 響，頂多落盤時占用點10資源而已。潛在瓶頸點出現(xiàn)fork。調(diào)用上Under Linux, fork() is implemented using copy - on - wri te pages, so the only penalty that it incurs is the time and memory required to duplicate theparent* s page tables

4、, and to create a unique task structure for the child.如果父進程的頁表比擬大，fork()耗時就會相應(yīng)延長，且redis采 用了單工作進程模型，fork。執(zhí)行期間會阻塞所有用戶請求。當前redis實例的RSS已經(jīng)到達了 16Gtop - 07:46:06 up 996 days, 16:51,1 user,load average: 0.00, 0.00, 0.02Tasks: 162 total,1 running, 161 sleeping, 0 stopped, 0 zombieCpu(s): 0.5%us, 0.9%sy, 0.0%

5、ni, 98.6%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 32878868k total, 23987712k used, 8891156k free,394488k buffersSwap: 4194300k total,8180k used, 4186120k free, 5719452k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND姆絲 root 為 9竺g ：!我8 Q.Q 5” 4死？* s-server頁表大小33Mcatyproc/8844/status | grep

6、 - i pte VmPTE? 33840 kB采用strace跟蹤一下fork()耗時，在glibc里fork的調(diào)用實際 上映射到了更底層的clone系統(tǒng)調(diào)用，因指定-e trace:clone# strace - p 20324 - e trace=clone - Tclone (child stack=0,flags=CLONE_CHILDCLEARTIDCLONE_CHILD SETTID SIGCHL D, child_tidptr=0 x7f409d771a!0)130793 于此對應(yīng)的redis監(jiān)控指標為latest_fork usee:1014778兩者吻合，由此可以確認是re

7、dis定期bgsave引發(fā)的。最簡單的方法是禁用bgsave ,但這種行為有很大的風險，一旦主庫 被誤殺且在主從切換前又被迅速拉起，會導致redis數(shù)據(jù)全部喪失。查看redis的內(nèi)存利用率，存在很嚴重的內(nèi)存碎片，used_memory_human 8. 7Gused memory rss human 16. 1G這套redis馬上就要遷移，新環(huán)境實例的RSS只有8.8G, latest_fork_usec指標也下降到達了 0. 25s左右，和開發(fā)確認后可以滿 足應(yīng)用需求，遷移后應(yīng)用的定期卡頓現(xiàn)象有了很明顯的緩解。redis 4. 0引入了碎片自動回收功能，由參數(shù)activedefrag調(diào)控， 默認關(guān)閉。遷移后對老redis開啟了 activedefrag(其余參數(shù)保持默認值)，最 終 used_memory_rss_human 固定在 11G 左右，latest_fork_usec 在 0. 76s左右。新環(huán)境以后也可能會遭遇嚴重內(nèi)存碎片，屆時要么開啟 activedefrag,要么在維護時間段重啟實例，后者效果顯然更好一點。3、小結(jié)我們線上redis主從都開啟了 bgsave ,之前一直忽視了 bgsave/fork()