?

操作系統分配給 Redis 的內存有 6GB，通過指標 used_memory_human 發現存儲數據只使用了 4GB，為何會這樣？為何無法保存數據？

通過 CONFIG SET maxmemory 100mb或者在 redis.conf 配置文件設置 maxmemory 100mb Redis 內存占用限制。當達到內存最大值，會觸發內存淘汰策略刪除數據。

除此之外，當 key 達到過期時間，Redis 會有以下兩種刪除過期數據的策略：

• 后臺定時任務選取部分數據刪除；
• 惰性刪除。

具體原理請移步《Redis 的過期數據刪除那些事》。

?

假設 Redis 實例保存了 5GB 的數據，現在刪除了 2GB 數據，Redis 進程占用的內存一定會降低么？（也叫做 RSS，進程消耗內存頁數）。

答案是：可能依然占用了大約 5GB 的內存，即使 Redis 的數據只占用了 3GB 左右。

大家一定要設置maxmemory，否則 Redis 會繼續為新寫入的數據分配內存，無法分配就會導致應用程序報錯，當然不會導致宕機。

釋放的內存去哪了

?

明明刪除了數據，使用 top 命令查看，為何還是占用了那么多內存？

內存都去哪了？使用 info memory 命令獲取 Redis 內存相關指標，我列舉了幾個重要的數據：

127.0.0.1:6379>infomemory
#Memory
used_memory:1132832//Redis存儲數據占用的內存量
used_memory_human:1.08M//人類可讀形式返回內存總量
used_memory_rss:2977792//操作系統角度，進程占用的物理總內存
used_memory_rss_human:2.84M//used_memory_rss可讀性模式展示
used_memory_peak:1183808//內存使用的最大值，表示used_memory的峰值

used_memory_peak_human:1.13M//以可讀的格式返回used_memory_peak的值
used_memory_lua:37888 // Lua 引擎所消耗的內存大小。
used_memory_lua_human:37.00K
maxmemory:2147483648 //能使用的最大內存值，字節為單位。
maxmemory_human:2.00G//可讀形式
maxmemory_policy:noeviction//內存淘汰策略

//used_memory_rss/used_memory的比值，代表內存碎片率
mem_fragmentation_ratio:2.79

Redis 進程內存消耗主要由以下部分組成：

• Redis 自身啟動所占用的內存；
• 存儲對象數據內存；
• 緩沖區內存：主要由 client-output-buffer-limit 客戶端輸出緩沖區、復制積壓緩沖區、AOF 緩沖區。
• 內存碎片。

內存占用

Redis 自身空進程占用的內存很小可以忽略不計，對象內存是占比最大的一塊，里面存儲著所有的數據。

緩沖區內存在大流量場景容易失控，造成 Redis 內存不穩定，需要重點關注。

內存碎片過大會導致明明有空間可用，但是卻無法存儲數據。

碎片 = used_memory_rss 實際使用的物理內存（RSS 值）除以 used_memory 實際存儲數據內存。

什么是內存碎片

內存碎片會造成明明有內存空間空閑，可是卻無法存儲數據。舉個例子，你跟漂亮小姐姐去電影院看電影，肯定想連在一塊。

假設現在有 8 個座位，已經賣出了 4 張票，還有 4 張可以買。可是好巧不巧，買票的人很奇葩，分別間隔一個座位買票。

即使還有 4 個座位空閑，可是你卻買不到兩個座位連在一塊的票，厚禮蟹！

內存碎片

內存碎片形成原因

?

內存碎片是什么原因導致呢？

主要有兩個原因：

• 內存分配器的分配策略。
• 鍵值對的大小不一樣和刪改操作：Redis 頻繁做更新操作、大量過期數據刪除，釋放的空間（不夠連續）無法得到復用，導致碎片率上升。

接下來我分別探討實際發生的原因……

內存分配器的分配策略

Redis 默認的內存分配器采用 jemalloc，可選的分配器還有：glibc、tcmalloc。

內存分配器并不能做到按需分配，而是采用固定范圍的內存塊進行分配。

例如 8 字節、16 字節…..，2 KB，4KB，當申請內存最近接某個固定值的時候，jemalloc 會給它分配最接近固定值大小的空間。

這樣就會出現內存碎片，比如程序只需要 1.5 KB，內存分配器會分配 2KB 空間，那么這 0.5KB 就是碎片。

這么做的目的是減少內存分配次數，比如申請 22 字節的空間保存數據，jemalloc 就會分配 32 字節，如果后邊還要寫入 10 字節，就不需要再向操作系統申請空間了，可以使用之前申請的 32 字節。

刪除 key 的時候，Redis 并不會立馬把內存歸還給操作系統，出現這個情況是因為底層內存分配器管理導致，比如大多數已經刪除的 key 依然與其他有效的 key 分配在同一個內存頁中。

另外，分配器為了復用空閑的內存塊，原有 5GB 的數據中刪除了 2 GB 后，當再次添加數據到實例中，Redis 的 RSS 會保持穩定，不會增長太多。

因為內存分配器基本上復用了之前刪除釋放出來的 2GB 內存。

鍵值對大小不一樣和刪改操作

由于內存分配器是按照固定大小分配內存，所以通常分配的內存空間比實際數據占用的大小多一些，會造成碎片，降低內存的存儲效率。

另外，鍵值對的頻繁修改和刪除，導致內存空間的擴容和釋放，比如原本占用 32 字節的字符串，現在修改為占用 20 字節的字符串，那么釋放出的 12 字節就是空閑空間。

如果下一個數據存儲請求需要申請 13 字節的字符串，那么剛剛釋放的 12 字節空間無法使用，導致碎片。

碎片最大的問題：空間總量足夠大，但是這些內存不是連續的，可能大致無法存儲數據。

內存碎片解決之道

?

那該如何解決呢？

首先要確定是否發生了內存碎片，重點關注前面 INFO memory 命令提示的 mem_fragmentation_ratio 指標，表示內存碎片率：

mem_fragmentation_ratio=used_memory_rss/used_memory

如果 1 < 碎片率 < 1.5，可以認為是合理的，而大于 1.5 說明碎片已經超過 50%，我們需要采取一些手段解決碎片率過大的問題。

重啟大法

最簡單粗暴的方式就是重啟，如果沒有開啟持久化，數據會丟失。

開啟持久化的話，需要使用 RDB 或者 AOF 恢復數據，如果只有一個實例，數據大的話會導致恢復階段長時間無法提供服務，高可用大打折扣。

?

咋辦呢？碼哥靚仔

自動清理內存碎片

既然你都叫我靚仔了，就傾囊相助告訴你終極殺招：Redis 4.0 版本后，自身提供了一種內存碎片清理機制。

?

怎么清理呢？

很簡單，還是上面的例子，想要買兩張連在一塊的電影票。與與別人溝通調換下位置，就實現了。

對于 Redis 來說，當一塊連續的內存空間被劃分為好幾塊不連續的空間的時候，操作系統先把數據以依次挪動拼接在一塊，并釋放原來數據占據的空間，形成一塊連續空閑內存空間。。

如下圖所示：

碎片清理

自動清理內存碎片的代價

自動清理雖好，可不要肆意妄為，操作系統把數據移動到新位置，再把原有空間釋放是需要消耗資源的。

Redis 操作數據的指令是單線程，所以在數據復制移動的時候，只能等待清理碎片完成才能處理請求，造成性能損耗。

?

如何避免清理碎片對性能的影響又能實現自動清理呢？

好問題，通過以下兩個參數來控制內存碎片清理和結束時機，避免占用 CPU 過多，減少清理碎片對 Redis 處理請求的性能影響。

開啟自動內存碎片清理

CONFIGSETactivedefragyes

這只是開啟自動清理，何時清理要同時滿足以下兩個條件才會觸發清理操作。

清理的條件

active-defrag-ignore-bytes 200mb：內存碎片占用的內存達到 200MB，開始清理；

active-defrag-threshold-lower 20：內存碎片的空間占比超過系統分配給 Redis 空間的 20% ，開始清理。

避免對性能造成影響

清理時間有了，還需要控制清理對性能的影響。由一項兩個設置先分配清理碎片占用的 CPU 資源，保證既能正常清理碎片，又能避免對 Redis 處理請求的性能影響。

active-defrag-cycle-min 20：自動清理過程中，占用 CPU 時間的比例不低于 20%，從而保證能正常展開清理任務。

active-defrag-cycle-max 50：自動清理過程占用的 CPU 時間比例不能高于 50%，超過的話就立刻停止清理，避免對 Redis 的阻塞，造成高延遲。

總結

如果你發現明明 Redis 存儲數據的內存占用遠小于操作系統分配給 Redis 的內存，而又無法保存數據，那可能出現大量內存碎片了。

通過 info memory 命令，看下內存碎片mem_fragmentation_ratio 指標是否正常。

那么我們就開啟自動清理并合理設置清理時機和 CPU 資源占用，該機制涉及到內存拷貝，會對 Redis 性能造成潛在風險。

如果遇到 Redis 性能變慢，排查下是否由于清理碎片導致，如果是，那就調小 active-defrag-cycle-max 的值。

審核編輯 ：李倩