Redis因為開了AOF導致hang住的問題處理-創(chuàng)新互聯(lián)

問題描述

創(chuàng)新互聯(lián)長期為千余家客戶提供的網(wǎng)站建設(shè)服務(wù)，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為魯?shù)槠髽I(yè)提供專業(yè)的網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計，魯?shù)榫W(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

業(yè)務(wù)反饋正常有個接口正常訪問在100ms以內(nèi),有時候調(diào)用時長會要10多s,根據(jù)業(yè)務(wù)提供的時間查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處理完每個事件后會調(diào)用write(2)將變化寫入kernel的buffer，如果此時write(2)被阻塞，Redis就不能處理下一個事件。

Linux規(guī)定執(zhí)行write(2)時，如果對同一個文件正在執(zhí)行fdatasync(2)將kernel buffer寫入物理磁盤，或者有system wide sync在執(zhí)行，write(2)會被Block住，整個Redis被Block住。

如果系統(tǒng)IO繁忙，比如有別的應(yīng)用在寫盤，或者Redis自己在AOF rewrite或RDB snapshot(雖然此時寫入的是另一個臨時文件，雖然各自都在連續(xù)寫，但兩個文件間的切換使得磁盤磁頭的尋道時間加長），就可能導致fdatasync(2)遲遲未能完成從而Block住write(2)，Block住整個Redis。

為了更清晰的看到fdatasync(2)的執(zhí)行時長，可以使用”strace -p (pid of redis server) -T -e -f trace=fdatasync”，但會影響系統(tǒng)性能。

Redis提供了一個自救的方式，當發(fā)現(xiàn)文件有在執(zhí)行fdatasync(2)時，就先不調(diào)用write(2)，只存在cache里，免得被Block。但如果已經(jīng)超過兩秒都還是這個樣子，則會硬著頭皮執(zhí)行write(2)，即使redis會被Block住。

此時那句要命的log會打印：“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-cli INFO可以看到aof_delayed_fsync的值被加1。

因此，對于fsync設(shè)為everysec時丟失數(shù)據(jù)的可能性的最嚴謹說法是：如果有fdatasync在長時間的執(zhí)行，此時redis意外關(guān)閉會造成文件里不多于兩秒的數(shù)據(jù)丟失。

如果fdatasync運行正常，redis意外關(guān)閉沒有影響，只有當操作系統(tǒng)crash時才會造成少于1秒的數(shù)據(jù)丟失。

解決方法

方法一：關(guān)閉aof

這個方法需要和業(yè)務(wù)確認是否可行，個人認為如果采用redis主從+sentinel方式的話主節(jié)點掛了從節(jié)點會自己提升為主點，主節(jié)點恢復后全量同步一次數(shù)據(jù)就可以了，關(guān)系也不是太大

方法二：修改系統(tǒng)配置

原來是AOF rewrite時一直埋頭的調(diào)用write(2)，由系統(tǒng)自己去觸發(fā)sync。在RedHat Enterprise 6里，默認配置vm.dirty_background_ratio=10，也就是占用了10%的可用內(nèi)存才會開始后臺flush，而我的服務(wù)器有8G內(nèi)存。

很明顯一次flush太多數(shù)據(jù)會造成阻塞，所以最后果斷設(shè)置了sysctl vm.dirty_bytes=33554432(32M)，問題解決。

然后提了個issue，AOF rewrite時定時也執(zhí)行一下fdatasync嘛， antirez回復新版中，AOF rewrite時32M就會重寫主動調(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

驗證修改是否成功

>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小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。

新聞名稱：Redis因為開了AOF導致hang住的問題處理-創(chuàng)新互聯(lián)
文章位置：http://bm7419.com/article8/dcoiop.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供建站公司、面包屑導航、外貿(mào)建站、自適應(yīng)網(wǎng)站、微信公眾號、用戶體驗

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)