?最近查看了一下redis運行狀況，發現公司測試服務器的redis內存不太夠用，但是實際占用內存的數據量其實不大，以前也沒有這種情況，之前在cache層新增了一個防刷積分任務的邏輯才會這樣，搜索一下原因，發現原來是產生了大量的內存碎片。

首先，查看redis的內存狀態，要用info memory指令

?

圖中幾個參數的意義：

1、used_memory：

已經使用了的內存大小，包括redis進程內部開銷和你的cache的數據所占用的內存，單位byte。

2、used_memory_human：

用戶數據所占用的內存，就是你緩存的數據的大小。

3、used_memory_rss：（rss for Resident Set Size）

表示redis物理內存的大小，即向OS申請了多少內存使用與used_memory的區別在后面解釋。

4、used_memory_peak：

redis內存使用的峰值。

5、used_memory_peak_human：

用戶cache數據的峰值大小。

6、used_memory_lua：

執行lua腳本所占用的內存。

7、mem_fragmentation_ratio：

內存碎片率，計算公式：

ratio指數>1表明有內存碎片，越大表明越多，<1表明正在使用虛擬內存，虛擬內存其實就是硬盤，性能比內存低得多，這是應該增強機器的內存以提高性能。一般來說，mem_fragmentation_ratio的數值在1 ~ 1.5之間是比較健康的。

8、mem_allocator：

在編譯時指定的Redis使用的內存分配器，可以是libc、jemalloc、tcmalloc，默認是jemalloc。jemalloc在64位系統中，將內存空間劃分為小、大、巨大三個范圍；每個范圍內又劃分了許多小的內存塊單位；存儲數據的時候，會選擇大小最合適的內存塊進行存儲。
jemalloc劃分的內存單元如下圖所示：

?

----------------------------------------------------- 分割線 ------------------------------------------------

產生原因

可以這樣認為，redis產生內存碎片有兩個原因，
A：redis自身的內存分配器。
B：修改cache的值，且修改后的value與原來value的大小差異較大。

進程需要用內存的話，會先通過OS向device申請，然后才能夠使用。一般進程在不需要使用的時候，會釋放掉這部分內存并返回給device。但是redis作者可能為了更高的性能，所以在redis中實現了自己的內存分配器來管理內存，不會馬上返還內存，不用每次都向OS申請了，從而實現高性能。

但是，在內存分配器的那張圖片我們知道，redis的每個k-v對初始化的內存大小是最適合的，當這個value改變的并且原來內存大小不適用的時候，就需要重新分配內存了。（但是value存比原來小不知道會不會產生碎片）。重新分配之后，就會有一部分內存redis無法正常回收，一直占用著。

----------------------------------------------------- 分割線 ------------------------------------------------

知道了原因就可以解決問題了，網上找到了兩個解決方案：
1、重啟redis服務，簡單粗暴。
2、redis4.0以上可以使用新增指令來手動回收內存碎片，配置監控使用性能更佳，具體大家可以自己去查。

這里提個問題，如果是單機redis，想要不停服務重啟redis，大家有什么好的想法？

總結

以上是生活随笔為你收集整理的redis调优 -- 内存碎片的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。