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

Fork操作

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

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

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

fork 耗時問題定位:

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

如何改善 fork 操作的耗時:

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

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

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

CPU

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

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

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

硬盤

• 硬盤開銷分析

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

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

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

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

內(nèi)存

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

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

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

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

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

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

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

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

AOF追加阻塞

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

阻塞流程分析：

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

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

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

AOF阻塞問題定位：

• 每當發(fā)生AOF追加阻塞事件發(fā)生時，在info Persistence統(tǒng)計中， aof_delayed_fsync指標會累加，查看這個指標方便定位AOF阻塞問題。
• AOF同步最多允許2秒的延遲，當延遲發(fā)生時說明硬盤存在高負載問 題，可以通過監(jiān)控工具如iotop，定位消耗硬盤IO資源的進程
• 發(fā)生 AOF 阻塞時, 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

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

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

總結(jié)

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

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