今天主要分享繼Redis持久化方式RDB、AOF之后的一些常用的Redis問題定位于優(yōu)化方式。這里主要CPU、內(nèi)存、磁盤在三個(gè)維度去分析問題！

Fork操作

當(dāng)Redis做RDB或AOF重寫時(shí)，一個(gè)必不可少的操作就是執(zhí)行fork操作創(chuàng)建子進(jìn)程，對(duì)于大多數(shù)操作系統(tǒng)來說fork是個(gè)重量級(jí)操作

雖然fork創(chuàng)建的子進(jìn)程不需要拷貝父進(jìn)程的物理內(nèi)存空間，但是會(huì)復(fù)制父進(jìn)程的空間內(nèi)存頁表。例如對(duì)于10GB的Redis進(jìn)程，需要復(fù)制大約20MB的內(nèi)存頁表，因此fork 操作耗時(shí)跟進(jìn)程總內(nèi)存量息息相關(guān)，如果使用虛擬化技術(shù)，特別是Xen虛擬 機(jī)，fork操作會(huì)更耗時(shí)

• 在做 RDB 或 AOF 重寫時(shí), fork 是必不可少的
• 對(duì)于大多數(shù)操作系統(tǒng)來說, fork 是個(gè)重量級(jí)錯(cuò)誤
• fork 會(huì)復(fù)制符進(jìn)程的空間內(nèi)存頁表
• 如果使用虛擬化技術(shù), 特別是 Xen 虛擬機(jī), fork 操作會(huì)更耗時(shí)

fork 耗時(shí)問題定位:

• 高流量的 Redis 實(shí)例 ops 可達(dá)5萬以上
• 正常情況 fork 耗時(shí)應(yīng)該是每 GB 消耗 20ms 左右
• 可以用 info stats 命令查看 latest_fork_usec 指標(biāo), 獲取最近一次 fork 操作耗時(shí), 單位微秒

如何改善 fork 操作的耗時(shí):

• 優(yōu)先使用物理機(jī)或者高效支持 fork 操作的虛擬化技術(shù), 避免使用 Xen
• 控制 Redis 實(shí)例最大可用內(nèi)存, fork 耗時(shí)跟內(nèi)存量成正比, 線上建議每個(gè) Redis 實(shí)例內(nèi)存控制在 10GB 以內(nèi)
• 合理配置 Linux 內(nèi)存分配策略, 避免物理內(nèi)存不足導(dǎo)致 fork 失敗, 具體細(xì)節(jié)見12.1節(jié) “Linux 配置優(yōu)化”
• 降低 fork 操作的頻率, 如適度放寬 AOF 自動(dòng)觸發(fā)時(shí)機(jī), 避免不必要的全量復(fù)制等

子進(jìn)程開銷進(jìn)程與優(yōu)化

子進(jìn)程負(fù)責(zé)AOF或者RDB文件的重寫，它的運(yùn)行過程主要涉及CPU、內(nèi)存、硬盤三部分的消耗

CPU

• CPU 開銷分析。子進(jìn)程負(fù)責(zé)把進(jìn)程內(nèi)的數(shù)據(jù)分批寫入文件, 這個(gè)過程屬于 CPU 密集操作, 通常子進(jìn)程對(duì)單核 CPU 利用率接近90%
• CPU 消耗優(yōu)化。Redis 是 CPU 密集型服務(wù), 不要做綁定單核 CPU 操作。由于子進(jìn)程非常消耗 CPU, 會(huì)和父進(jìn)程產(chǎn)生單核資源競(jìng)爭(zhēng).

不要和其他 CPU 密集型服務(wù)部署在一起, 造成 CPU 過度競(jìng)爭(zhēng)

如果部署多個(gè) Redis 實(shí)例, 盡量保證同一時(shí)刻只有一個(gè)子進(jìn)程執(zhí)行重寫工作, 具體細(xì)節(jié)見5.4節(jié)多實(shí)例部署

硬盤

• 硬盤開銷分析

子進(jìn)程主要職責(zé)是把 AOF 或者 RDB 文件寫入硬盤持久化。勢(shì)必造成硬盤寫入壓力。根據(jù) Redis 重寫 AOF/RDB 的數(shù)據(jù)量, 結(jié)合系統(tǒng)工具如 sar、iostat、iotop 等, 可分析出重寫期間硬盤負(fù)載情況

• 硬盤開銷優(yōu)化

• • 不要和其他高硬盤負(fù)載的服務(wù)部署在一起。如: 存儲(chǔ)服務(wù)、消息隊(duì)列服務(wù)等
  • AOF 重寫時(shí)會(huì)消耗大量硬盤 IO, 可以開啟配置 no-appendfsync-on-rewrite, 默認(rèn)關(guān)閉。表示在 AOF 重寫期間不做 fsync 操作
  • 當(dāng)開啟 AOF 功能的 Redis 用于高流量寫入場(chǎng)景時(shí), 如果使用普通機(jī)械磁盤, 寫入吞吐一般在 100MB/s 左右, 這時(shí) Redis 實(shí)例的瓶頸主要在 AOF 同步硬盤上
  • 對(duì)于單機(jī)配置多個(gè) Redis 實(shí)例的情況, 可以配置不同實(shí)例分盤存儲(chǔ) AOF 文件, 分?jǐn)傆脖P寫入壓力

配置 no-appendfsync-on-rewrite=yes 時(shí), 在極端情況下可能丟失整個(gè) AOF 重寫期間的數(shù)據(jù),需要根據(jù)數(shù)據(jù)安全性決定是否配置

內(nèi)存

• 內(nèi)存消耗分析

子進(jìn)程通過 fork 操作產(chǎn)生, 占用內(nèi)存大小等同于父進(jìn)程, 理論上需要兩倍的內(nèi)存來完成持久化操作, 但 Linux 有寫時(shí)復(fù)制機(jī)制 (copy-on-write)。父子進(jìn)程會(huì)共享相同的物理內(nèi)存頁, 當(dāng)父進(jìn)程處理寫請(qǐng)求時(shí)會(huì)把要修改的頁創(chuàng)建副本, 而子進(jìn)程在 fork 操作過程中共享整個(gè)父進(jìn)程內(nèi)存快照。

• 內(nèi)存消耗監(jiān)控

• • RDB 重寫: 被修改的內(nèi)存頁可以等價(jià)認(rèn)為 RDB 重寫的消耗
  • AOF 重寫: 被修改的內(nèi)存頁 + AOF 重寫緩沖區(qū)

• 內(nèi)存消耗優(yōu)化

• • 如果部署多個(gè) Redis 實(shí)例, 盡量保證同一時(shí)刻只有一個(gè)子進(jìn)程在工作
  • 避免在大量寫入時(shí)做子進(jìn)程重寫操作, 這樣將導(dǎo)致父進(jìn)程維護(hù)大量頁副本, 造成內(nèi)存消耗

Transparent Huge Pages(THP) 是 Linux kernel 在2.6.38增加的功能, 支持 huge page (2MB) 頁分配, 會(huì)降低 fork 速度, 默認(rèn)開啟. 當(dāng)開啟時(shí), 在 fork 后會(huì)大幅增加重寫期間父進(jìn)程的內(nèi)存消耗, 建議關(guān)閉:

sudo?echo?never>/sys/kernel/mm/transparent_hugepage/enabled

AOF追加阻塞

當(dāng)開啟AOF持久化時(shí)，常用的同步硬盤的策略是everysec，用于平衡性 能和數(shù)據(jù)安全性。對(duì)于這種方式，Redis使用另一條線程每秒執(zhí)行fsync同步 硬盤。當(dāng)系統(tǒng)硬盤資源繁忙時(shí)，會(huì)造成Redis主線程阻塞！如下圖所示

阻塞流程分析：

• 如果距上次同步成功時(shí)間在2秒內(nèi)，主線程直接返回
• 如果距上次同步成功時(shí)間超過2秒，主線程將會(huì)阻塞，直到同步操作完 成。
  • 主線程負(fù)責(zé)寫入AOF緩沖區(qū)
  • AOF線程負(fù)責(zé)每秒執(zhí)行一次同步磁盤操作，并記錄最近一次同步時(shí) 間
  • 主線程負(fù)責(zé)對(duì)比上次AOF同步時(shí)間：

通過對(duì)AOF阻塞流程可以發(fā)現(xiàn)兩個(gè)問題：

• everysec配置最多可能丟失2秒數(shù)據(jù)，不是1秒
• 如果系統(tǒng)fsync緩慢，將會(huì)導(dǎo)致Redis主線程阻塞影響效率

AOF阻塞問題定位：

• 每當(dāng)發(fā)生AOF追加阻塞事件發(fā)生時(shí)，在info Persistence統(tǒng)計(jì)中， aof_delayed_fsync指標(biāo)會(huì)累加，查看這個(gè)指標(biāo)方便定位AOF阻塞問題。
• AOF同步最多允許2秒的延遲，當(dāng)延遲發(fā)生時(shí)說明硬盤存在高負(fù)載問 題，可以通過監(jiān)控工具如iotop，定位消耗硬盤IO資源的進(jìn)程
• 發(fā)生 AOF 阻塞時(shí), Redis 輸出如下日志, 用于記錄 AOF fsync 阻塞導(dǎo)致拖慢 Redis 服務(wù)的行為

Asynchronous?AOF?fsync?is?taking?too?long?(disk?is?busy).?Writing?the?AOF?bufferwithout?waiting?for?fsync?to?complete,?this?may?slow?down?Redis

• 每當(dāng)發(fā)生 AOF 追加阻塞事件發(fā)生時(shí), 在info Persistence 統(tǒng)計(jì)中, aof_delayed_fsync 指標(biāo)會(huì)累加, 查看這個(gè)指標(biāo)方便定位 AOF 阻塞問題
• AOF 同步最多允許2秒的延遲, 當(dāng)延遲發(fā)生時(shí)說明硬盤存在高負(fù)載問題, 可以通過監(jiān)控工具如 iotop, 定位消耗硬盤 IO 資源的進(jìn)程

更多原創(chuàng)技術(shù)分享，關(guān)注公眾號(hào)：碼農(nóng)架構(gòu)

總結(jié)

以上是生活随笔為你收集整理的查看redis aof内存_Redis持久化问题定位与优化技巧的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。