問題描述
業(yè)務(wù)反饋正常有個(gè)接口正常訪問在100ms以內(nèi),有時(shí)候調(diào)用時(shí)長會要10多s,根據(jù)業(yè)務(wù)提供的時(shí)間查redis日志,以現(xiàn)有如下記錄:
8788:M 24 Aug 01:21:26.008 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis. 8788:M 24 Aug 01:21:45.006 * Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.查看redis aof相關(guān)配置
127.0.0.1:6390> config get *append* 1) "no-appendfsync-on-rewrite" 2) "yes" 3) "appendfsync" 4) "everysec" 5) "appendonly" 6) "yes"查看rdb的配置:
127.0.0.1:6390> config get save 1) "save" 2) ""查看redis的版本:
127.0.0.1:6390> info server # Server redis_version:3.2.4故障分析
打開AOF持久化功能后, Redis處理完每個(gè)事件后會調(diào)用write(2)將變化寫入kernel的buffer,如果此時(shí)write(2)被阻塞,Redis就不能處理下一個(gè)事件。
Linux規(guī)定執(zhí)行write(2)時(shí),如果對同一個(gè)文件正在執(zhí)行fdatasync(2)將kernel buffer寫入物理磁盤,或者有system wide sync在執(zhí)行,write(2)會被Block住,整個(gè)Redis被Block住。
如果系統(tǒng)IO繁忙,比如有別的應(yīng)用在寫盤,或者Redis自己在AOF rewrite或RDB snapshot(雖然此時(shí)寫入的是另一個(gè)臨時(shí)文件,雖然各自都在連續(xù)寫,但兩個(gè)文件間的切換使得磁盤磁頭的尋道時(shí)間加長),就可能導(dǎo)致fdatasync(2)遲遲未能完成從而Block住write(2),Block住整個(gè)Redis。
為了更清晰的看到fdatasync(2)的執(zhí)行時(shí)長,可以使用”strace -p (pid of redis server) -T -e -f trace=fdatasync”,但會影響系統(tǒng)性能。
Redis提供了一個(gè)自救的方式,當(dāng)發(fā)現(xiàn)文件有在執(zhí)行fdatasync(2)時(shí),就先不調(diào)用write(2),只存在cache里,免得被Block。但如果已經(jīng)超過兩秒都還是這個(gè)樣子,則會硬著頭皮執(zhí)行write(2),即使redis會被Block住。
此時(shí)那句要命的log會打?。骸癆synchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.”
之后用redis-cli INFO可以看到aof_delayed_fsync的值被加1。
因此,對于fsync設(shè)為everysec時(shí)丟失數(shù)據(jù)的可能性的最嚴(yán)謹(jǐn)說法是:如果有fdatasync在長時(shí)間的執(zhí)行,此時(shí)redis意外關(guān)閉會造成文件里不多于兩秒的數(shù)據(jù)丟失。
如果fdatasync運(yùn)行正常,redis意外關(guān)閉沒有影響,只有當(dāng)操作系統(tǒng)crash時(shí)才會造成少于1秒的數(shù)據(jù)丟失。
解決方法
方法一:關(guān)閉aof
這個(gè)方法需要和業(yè)務(wù)確認(rèn)是否可行,個(gè)人認(rèn)為如果采用redis主從+sentinel方式的話主節(jié)點(diǎn)掛了從節(jié)點(diǎn)會自己提升為主點(diǎn),主節(jié)點(diǎn)恢復(fù)后全量同步一次數(shù)據(jù)就可以了,關(guān)系也不是太大
方法二:修改系統(tǒng)配置
原來是AOF rewrite時(shí)一直埋頭的調(diào)用write(2),由系統(tǒng)自己去觸發(fā)sync。在RedHat Enterprise 6里,默認(rèn)配置vm.dirty_background_ratio=10,也就是占用了10%的可用內(nèi)存才會開始后臺flush,而我的服務(wù)器有8G內(nèi)存。
很明顯一次flush太多數(shù)據(jù)會造成阻塞,所以最后果斷設(shè)置了sysctl vm.dirty_bytes=33554432(32M),問題解決。
然后提了個(gè)issue,AOF rewrite時(shí)定時(shí)也執(zhí)行一下fdatasync嘛, antirez回復(fù)新版中,AOF rewrite時(shí)32M就會重寫主動(dòng)調(diào)用fdatasync。
查看一下系統(tǒng)內(nèi)核參數(shù)
>sysctl -a | grep dirty_background_ratio vm.dirty_background_ratio = 10>sysctl -a | grep vm.dirty_bytes vm.dirty_bytes = 0嘗試修改一下配置文件/etc/sysctl.conf,并使配置立即生效
echo "vm.dirty_bytes=33554432" >> /etc/sysctl.conf sysctl -p驗(yàn)證修改是否成功
>sysctl -a | grep vm.dirty_bytes vm.dirty_bytes = 33554432參考:
https://ningyu1.github.io/site/post/32-redis-aof/
https://redis.io/topics/latency
另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢,專為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場景需求。
新聞名稱:Redis因?yàn)殚_了AOF導(dǎo)致hang住的問題處理-創(chuàng)新互聯(lián)
文章位置:http://www.rwnh.cn/article8/dcoiop.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供建站公司、面包屑導(dǎo)航、外貿(mào)建站、自適應(yīng)網(wǎng)站、微信公眾號、用戶體驗(yàn)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容