Redis關(guān)于內(nèi)存碎片的解決方法

更新時間：2024年07月19日 09:37:33 作者：矩陣科學(xué)

今天生產(chǎn)機報內(nèi)存爆滿異常被叫過去查看問題,通過各種排除最終定位到了Redis的內(nèi)存碎片的問題,這篇博客將詳細介紹Redis內(nèi)存碎片問題并給出最佳實踐解決此問題,需要的朋友可以參考下

Redis的內(nèi)存碎片原理

先引用Redis官方的原話：

當(dāng)鍵被刪除時，Redis 并不總是會釋放（歸還）內(nèi)存給操作系統(tǒng)。這不是 Redis 的特別之處，但這是大多數(shù) malloc() 實現(xiàn)的工作方式。例如，如果您用 5GB 的數(shù)據(jù)填充一個實例，然后刪除相當(dāng)于 2GB 的數(shù)據(jù)，則駐留集大?。ㄒ卜Q為 RSS，即進程消耗的內(nèi)存頁數(shù)）可能仍約為 5GB，即使 Redis 聲稱用戶內(nèi)存約為 3GB。發(fā)生這種情況的原因是底層分配器無法輕松釋放內(nèi)存。例如，通常大多數(shù)被刪除的鍵都分配在與仍然存在的其他鍵相同的頁面上。

內(nèi)部碎片

首先介紹一下Redis內(nèi)存管理原理，操作系統(tǒng)內(nèi)存管理思想一致是按照固定大小內(nèi)存單位來分配而非按需分配，為了減少頻繁分配內(nèi)存，Linux下默認一次分配內(nèi)存單位是4KB，Redis的內(nèi)存也是按照單位進行分配的，例如范圍有 8、16、32、64、128、256、512 字節(jié)為單位的大小，也有大的內(nèi)存單位如2KB、4KB等。例如存儲一個鍵值對大小為29字節(jié)，則會分配一個32字節(jié)的連續(xù)內(nèi)存。那么就會造成3個字節(jié)的內(nèi)存碎片，這3個字節(jié)就不會被分配給其他鍵值對。這個是內(nèi)在的原因，稱為內(nèi)部碎片。

在這里插入圖片描述

外部碎片

Redis分配內(nèi)存時，會根據(jù)需要申請一段連續(xù)的內(nèi)存空間。但當(dāng)Redis刪除或修改數(shù)據(jù)時，釋放的內(nèi)存空間并不一定能被立即重新利用，尤其是當(dāng)這些空閑內(nèi)存空間大小不一致時，就可能導(dǎo)致內(nèi)存碎片的出現(xiàn)。Redis釋放的內(nèi)存有可能是不連續(xù)的，這種不連續(xù)的內(nèi)存很可能無法再次使用，最終造成了內(nèi)存的浪費，這種空閑但是無法使用的內(nèi)存便是內(nèi)存碎片。比如說現(xiàn)在客戶端存了100個鍵值對（每個鍵值對大小53字節(jié)），占用了一片連續(xù)的存儲空間，分配內(nèi)存單位為32字節(jié)，一共用了640個字節(jié)，如果這個時候刪除了中間的1個鍵值對，那么中間將空出64個字節(jié)，這64個字節(jié)可能對于大于32字節(jié)的鍵值對無法有效使用（小于32字節(jié)的內(nèi)存申請可能可以重新分配，但是概率較小），就會造成內(nèi)存碎片。這些碎片稱為外部碎片。

在這里插入圖片描述

總結(jié)：使用大白話說就是固定的內(nèi)存分配單位就像一個個標(biāo)準(zhǔn)化的箱子，箱子有8、16、32、64等規(guī)格的，而你的物品假設(shè)為33規(guī)格的那么就需要連續(xù)的33內(nèi)存存放，因此申請內(nèi)存的時候可以分配連續(xù)的32+8的內(nèi)存，但是如果中間只有32的內(nèi)存，另外的8是不連續(xù)的，那么是無法分配這32內(nèi)存，只能空著。除非剛好有一個小于32的對象，就可以被分配給到。

為了提高內(nèi)存使用的效率，Redis內(nèi)部使用內(nèi)存分配器來對內(nèi)存的申請和釋放進行管理。Redis使用的內(nèi)存分配器默認是jemalloc。

會導(dǎo)致的問題

一般而言，存取較小的鍵值對不太會導(dǎo)致內(nèi)存碎片的問題，但是如果存儲非常大的復(fù)合數(shù)據(jù)結(jié)構(gòu)（Hash、Set、List），并且對這些對象頻繁的修改、刪除等操作，那么可能這個對象的實際大小假設(shè)為1.5GB，但是存儲系統(tǒng)分配給Redis用來存儲這個對象的實際內(nèi)存為8個GB。這就會導(dǎo)致內(nèi)存爆滿的問題，而多出的這6.5GB其實就是內(nèi)存碎片導(dǎo)致的。

查看內(nèi)存碎片

登錄到Redis客戶端，輸入命令info或者info memory就可以查看到內(nèi)存信息，如下：

127.0.0.1:7001> info

# Server
redis_version:7.2.5
...
# Memory
used_memory:1853040
used_memory_human:1.77M
used_memory_rss:9101312
used_memory_rss_human:8.68M
used_memory_peak:1902032
used_memory_peak_human:1.81M
used_memory_peak_perc:97.42%
used_memory_overhead:1632076
used_memory_startup:1596680
used_memory_dataset:220964
used_memory_dataset_perc:86.19%
allocator_allocated:2207416
allocator_active:2572288
allocator_resident:4976640
total_system_memory:1019793408
total_system_memory_human:972.55M
used_memory_lua:31744
used_memory_vm_eval:31744
used_memory_lua_human:31.00K
used_memory_scripts_eval:0
number_of_cached_scripts:0
number_of_functions:0
number_of_libraries:0
used_memory_vm_functions:32768
used_memory_vm_total:64512
used_memory_vm_total_human:63.00K
used_memory_functions:184
used_memory_scripts:184
used_memory_scripts_human:184B
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.17
allocator_frag_bytes:364872
allocator_rss_ratio:1.93
allocator_rss_bytes:2404352
rss_overhead_ratio:1.83
rss_overhead_bytes:4124672
mem_fragmentation_ratio:4.97
mem_fragmentation_bytes:7271160
mem_not_counted_for_evict:0
mem_replication_backlog:20508
mem_total_replication_buffers:20504
mem_clients_slaves:0
mem_clients_normal:3856
mem_cluster_links:10720
mem_aof_buffer:0
mem_allocator:jemalloc-5.3.0
active_defrag_running:0
lazyfree_pending_objects:0
lazyfreed_objects:0

對上面字段解釋如下：

內(nèi)存使用概述
used_memory: Redis 分配的內(nèi)存總量（字節(jié)）。
used_memory_human: 以人類可讀格式表示的 used_memory（例如：1.77M）。
used_memory_rss: 從操作系統(tǒng)角度來看，Redis 使用的實際內(nèi)存（駐留集大?。?。
used_memory_rss_human: 以人類可讀格式表示的 used_memory_rss（例如：8.68M）。
內(nèi)存峰值
used_memory_peak: Redis 歷史上使用的最大內(nèi)存量。
used_memory_peak_human: 以人類可讀格式表示的 used_memory_peak。
used_memory_peak_perc: 當(dāng)前內(nèi)存使用量相對于歷史峰值的百分比。
內(nèi)存開銷
used_memory_overhead: Redis 的內(nèi)存開銷，包括數(shù)據(jù)結(jié)構(gòu)、客戶端連接、備份等的內(nèi)存。
used_memory_startup: Redis 啟動時消耗的初始內(nèi)存。
used_memory_dataset: 實際存儲數(shù)據(jù)所使用的內(nèi)存。
used_memory_dataset_perc: 數(shù)據(jù)集占用的內(nèi)存相對于總內(nèi)存使用量的百分比。
內(nèi)存分配器
allocator_allocated: 通過內(nèi)存分配器 jemalloc 分配的內(nèi)存。
allocator_active: 內(nèi)存分配器 jemalloc 實際使用的內(nèi)存。
allocator_resident: jemalloc 分配的駐留內(nèi)存。
系統(tǒng)內(nèi)存
total_system_memory: 系統(tǒng)總內(nèi)存。
total_system_memory_human: 以人類可讀格式表示的系統(tǒng)總內(nèi)存。
Lua 腳本
used_memory_lua: Lua 腳本使用的內(nèi)存。
used_memory_vm_eval: Lua 腳本虛擬機使用的內(nèi)存（評估腳本時）。
used_memory_lua_human: 以人類可讀格式表示的 used_memory_lua。
used_memory_scripts_eval: 用于腳本評估的內(nèi)存。
緩存的腳本
number_of_cached_scripts: 緩存的腳本數(shù)量。
number_of_functions: 注冊的函數(shù)數(shù)量。
number_of_libraries: 加載的庫數(shù)量。
虛擬內(nèi)存
used_memory_vm_functions: 虛擬內(nèi)存中函數(shù)使用的內(nèi)存。
used_memory_vm_total: 虛擬內(nèi)存總使用量。
used_memory_vm_total_human: 以人類可讀格式表示的 used_memory_vm_total。
腳本和函數(shù)
used_memory_functions: 函數(shù)使用的內(nèi)存。
used_memory_scripts: 腳本使用的內(nèi)存。
used_memory_scripts_human: 以人類可讀格式表示的 used_memory_scripts。
最大內(nèi)存設(shè)置
maxmemory: Redis 配置的最大可用內(nèi)存。
maxmemory_human: 以人類可讀格式表示的 maxmemory。
maxmemory_policy: 內(nèi)存超過最大值時的處理策略（例如：noeviction 表示不驅(qū)逐）。
內(nèi)存碎片率
allocator_frag_ratio: 內(nèi)存分配器碎片率（分配的內(nèi)存與實際使用的內(nèi)存之比）。
allocator_frag_bytes: 內(nèi)存分配器碎片字節(jié)數(shù)。
allocator_rss_ratio: 分配器駐留集大小比率（分配的內(nèi)存與駐留內(nèi)存之比）。
allocator_rss_bytes: 分配器駐留內(nèi)存字節(jié)數(shù)。
rss_overhead_ratio: RSS 的開銷比率。
rss_overhead_bytes: RSS 的開銷字節(jié)數(shù)。
mem_fragmentation_ratio: 內(nèi)存碎片總比率。
mem_fragmentation_bytes: 內(nèi)存碎片字節(jié)數(shù)。
其他內(nèi)存統(tǒng)計
mem_not_counted_for_evict: 不計入驅(qū)逐的內(nèi)存。
mem_replication_backlog: 復(fù)制日志的內(nèi)存。
mem_total_replication_buffers: 總復(fù)制緩沖區(qū)的內(nèi)存。
mem_clients_slaves: 從客戶端使用的內(nèi)存。
mem_clients_normal: 正常客戶端使用的內(nèi)存。
mem_cluster_links: 集群鏈接使用的內(nèi)存。
mem_aof_buffer: AOF（追加文件）緩沖區(qū)的內(nèi)存。
mem_allocator: 使用的內(nèi)存分配器（如 jemalloc-5.3.0）。
active_defrag_running: 活動的碎片整理狀態(tài)（是否正在運行）。
lazyfree_pending_objects: 懶惰釋放待處理對象的數(shù)量。
lazyfreed_objects: 懶惰釋放的對象數(shù)量。

最重要的是找到如下幾個字段：

INFO memory
# Memory
used_memory:1074741736
used_memory_human:1024.30M
used_memory_rss:1997159792
used_memory_rss_human:1.86G
…
mem_fragmentation_ratio:1.86

這里有一個mem_fragmentation_ratio指標(biāo)非常重要，它表示的就是Redis當(dāng)前的內(nèi)存碎片率。它是used_memory_rss和used_memory相除的結(jié)果：mem_fragmentation_ratio = used_memory_rss/ used_memory 。used_memory_rss 等于碎片內(nèi)存+時間數(shù)據(jù)使用內(nèi)存，也就是操作系統(tǒng)分給Redis的實際內(nèi)存。used_memory是Redis存儲數(shù)據(jù)實際使用的內(nèi)存?？梢园l(fā)現(xiàn)如果不存在碎片內(nèi)存，那么mem_fragmentation_ratio=1，但是這是最理想的情況，一般而言這個值為1.2較為健康，范圍如下：

1.5 > mem_fragmentation_ratio > 1：內(nèi)存碎片在合理范圍內(nèi)。
mem_fragmentation_ratio > 1.5：需要考慮降低內(nèi)存碎片率。
mem_fragmentation_ratio < 1：Redis沒有足夠的內(nèi)存可以使用了，會導(dǎo)致redis一部分的內(nèi)存數(shù)據(jù)會被換到swap中（硬盤中），之后redis訪問swap中的數(shù)據(jù)延遲會變大，性能下降。

解決方法

重啟Redis

低于4.0-RC3版本的Redis 并沒有內(nèi)置的內(nèi)存碎片整理工具。如果想要清理內(nèi)存碎片，可以通過重啟的方式。當(dāng)Redis重新啟動時，它會通過RDB持久化功能將數(shù)據(jù)存儲到磁盤，然后再從磁盤加載數(shù)據(jù)到內(nèi)存，這個過程可以有效地清理內(nèi)存碎片。但這種方法會導(dǎo)致服務(wù)的臨時中斷。因此非常不推薦！

配置 active-defrag

Active-defrag（主動碎片整理）是 Redis 的一個功能，用于在后臺自動整理內(nèi)存碎片，提升內(nèi)存利用率和性能。內(nèi)存碎片是指內(nèi)存塊之間存在空隙，導(dǎo)致內(nèi)存使用效率下降。通過主動碎片整理，Redis 可以減少這些空隙，提高內(nèi)存的有效利用。

從4.0-RC3版本開始引入了active-defrag 特性?？梢栽诓恢貑⒌那闆r下，自動進行碎片清理。開啟配置如下，此選項的默認值是關(guān)閉的，激活碎片整理可能會占據(jù)一些 CPU 時間。手動開啟如下：

redis> config set activedefrag yes

注意：自動清理內(nèi)存碎片的功能需要該Redis的內(nèi)存分配器是jemalloc時才能啟用。啟用后需要同時滿足下面2個參數(shù)的設(shè)置條件時才會觸發(fā)自動清理。如果使用手動開啟而redis.conf文件中沒有配置，那么會使用默認值進行碎片整理。

active-defrag-ignore-bytes 100mb    # 默認100MB,表示內(nèi)存碎片空間達到100MB時才會整理碎片
active-defrag-threshold-lower 10    # 默認10，表示內(nèi)存碎片空間占OS分配給redis的物理內(nèi)存空間的比例達到10%時，即碎片率為1.1才整理

注意：配置碎片自動整理會占用主線程，如果配置不合理會導(dǎo)致主線程阻塞，因此下面配置很關(guān)鍵。

active-defrag-cycle-min 1  # 默認1，表示自動清理過程所用 CPU 時間的比例不低于1%，保證清理能正常開展；
active-defrag-cycle-max 25 # 默認25，表示自動清理過程所用 CPU 時間的比例不高于 25%，一旦超過，就停止清理，從而避免在清理時，大量的內(nèi)存拷貝阻塞 Redis，導(dǎo)致響應(yīng)延遲升高。

另外，一開始也可以在配置文件中啟用和配置主動碎片整理，可以在 Redis 配置文件（redis.conf）中設(shè)置以下選項，下面的都是Redis7.0配置文件的默認值：

active-defrag yes #啟用或禁用主動碎片整理。
active-defrag-ignore-bytes 100mb #小于此值的內(nèi)存片段將被忽略，不進行碎片整理。
active-defrag-threshold-lower 10 # 低于此碎片率百分比時不進行碎片整理。（碎片率1.1）
active-defrag-threshold-upper 100 # 超過此碎片率百分比時最大限度進行碎片整理。（碎片率2）
active-defrag-cycle-min 1 # 最小碎片整理周期百分比，控制最小CPU資源用于碎片整理。
active-defrag-cycle-max 25 #最大碎片整理周期百分比，控制最大CPU資源用于碎片整理。
active-defrag-max-scan-fields 1000 #一次最大掃描字段個數(shù)

其他關(guān)于內(nèi)存的命令如下：

在Redis客戶端可以通過下面命令查看更加具體的內(nèi)存情況：

> MEMORY HELP
MEMORY DOCTOR                        - 輸出內(nèi)存問題報告
MEMORY USAGE <key> [SAMPLES <count>] - 估計key的內(nèi)存使用情況
MEMORY STATS                         - 顯示內(nèi)存使用情況詳細信息
MEMORY PURGE                         - 要求分配器釋放內(nèi)存，主線程阻塞式執(zhí)行
MEMORY MALLOC-STATS                  - 顯示分配器內(nèi)部統(tǒng)計信息

查看一個bigkey的內(nèi)存占用：

> memory usage mybigkey51344216

查看內(nèi)存詳細情況

> memory stats
peak.allocated #redis啟動以來，allocator分配的內(nèi)存峰值，單位字節(jié)；同INFO的used_memory_peak
2604763296
total.allocated #allocator 當(dāng)前分配的內(nèi)存總字節(jié)數(shù)；同 INFO命令used_memeory
595052416
startup.allocated #Redis啟動完成消耗的內(nèi)存字節(jié)數(shù)；同INFO的used_memory_startup
11403768
replication.backlog #Redis復(fù)制積壓緩存區(qū)內(nèi)存字節(jié)數(shù)；同INFO的repl_backlog_size
0
clients.slaves #所有副本節(jié)點內(nèi)存消耗總字節(jié)數(shù)(查詢輸出緩沖區(qū)，連接內(nèi)存消耗)
0
clients.normal #Redis所有常規(guī)客戶端內(nèi)存消耗總字節(jié)數(shù)(查詢輸出緩沖區(qū)，連接內(nèi)存消耗)
207724178
aof.buffer #當(dāng)前和重寫AOF緩沖區(qū)內(nèi)存消耗總字節(jié)數(shù)；同 INFO命令aof_buffer_length和aof_rewrite_buffer_length之和
0
lua.caches
30536
db.0
overhead.hashtable.main #每個數(shù)據(jù)庫中元數(shù)據(jù)占用的額外內(nèi)存字節(jié)數(shù)。（redis的db就是一張hash表，首先就是這張hash表使用的內(nèi)存，每一個key-value對都有一個dictEntry來記錄他們的關(guān)系，元信息便包含該db中所有dictEntry使用的內(nèi)存， redis使用redisObject來描述value所對應(yīng)的不同數(shù)據(jù)類型（string、list、hash、set、zset），那么redisObject占用的空間也計算在元信息中。
10823332
overhead.hashtable.expires #用于存儲key的過期時間耗費的內(nèi)存資源。
865120
db.1
overhead.hashtable.main
275384
overhead.hashtable.expires
77552
....
overhead.total #Redis 額外內(nèi)存消耗總字節(jié)數(shù)，例如：startup.allocated, replication.backlog, clients.slaves, clients.normal, aof.buffer 以及管理keyspace使用的內(nèi)部數(shù)據(jù)接口消耗的內(nèi)存字節(jié)數(shù) 同INFO的used_memory_overhead
233196498
keys.count #整個redis實例key的個數(shù)
183900
keys.bytes-per-key #每個key平均字節(jié)數(shù)
3173
dataset.bytes #Redis 實例中數(shù)據(jù)占用的總字節(jié)數(shù)，計算方法total.allocated減去overhead.total
361855918
dataset.percentage #Redis 數(shù)據(jù)消耗內(nèi)存占總內(nèi)存的百分比
61.998931884765625
peak.percentage #當(dāng)前內(nèi)存消耗占峰值內(nèi)存消耗的百分比
22.844778060913086
fragmentation #同 INFO的 mem_fragmentation_ratio
0.96442300081253052

注意：以上命令是使用了內(nèi)存分配器 jemalloc的情況下才能使用！Redis默認使用的是jemalloc分配器。 Redis 使用 jemalloc 作為默認的內(nèi)存分配器。jemalloc 會將內(nèi)存劃分為不同大小的塊，并在需要時分配和釋放這些內(nèi)存塊。然而，在某些情況下，jemalloc 可能不會立即將未使用的內(nèi)存返回給操作系統(tǒng)，這可能會導(dǎo)致內(nèi)存看起來被占用而實際并未被使用。通過 MEMORY PURGE命令，可以強制 jemalloc 進行內(nèi)存清理，將不再使用的內(nèi)存返回給操作系統(tǒng)。但這個命令是主線程執(zhí)行的，會阻塞其他命令。

最后注意在線上生產(chǎn)機上排查BigKey時最后把RDB文件拉取下來分析，禁止在生產(chǎn)機Master上使用如下命令尋找BigKey（主線程執(zhí)行，阻塞其他命令，非要用可以在Slave節(jié)點操作）：

redis-cli -p 9001 -a 12345678 --bigkeys

最佳實踐

看了這么多，有沒有想一個問題——為什么Redis官方默認配置設(shè)置activfrag = no ？。原因就是Redis內(nèi)置了jemalloc這樣的內(nèi)存分配神器，它能夠?qū)σ颜加玫目臻e內(nèi)存碎片利用到極致，Redis官方建議我們采用“鴕鳥算法”，即啥都不用做，只需要設(shè)置合適的maxmemory即可，即使碎片率非常大，后續(xù)的內(nèi)存也是安全的，因為jemalloc會自己去利用碎片。這里的邏輯就是：Redis在刪除鍵值的時候，會將內(nèi)存還給jemalloc而不是操作系統(tǒng)。這部分內(nèi)存可能是碎片，也可能不是，如果Redis需要申請內(nèi)存則先看內(nèi)存分配器是否有足夠的可分配內(nèi)存。額外的碎片過多是因為，Reids釋放了大量內(nèi)存，但jemalloc手中的大量的內(nèi)存沒有及時返回給操作系統(tǒng)，這可能是是因為沒有設(shè)置合適的maxmemory原因。這個時候，其實Redis繼續(xù)存入鍵值對并不會向操作系統(tǒng)申請內(nèi)存而是向jemalloc申請。因此，如果不設(shè)置maxmemory，那么Redis可能無限地向操作系統(tǒng)申請內(nèi)存，而不是jemalloc中的碎片內(nèi)存。下面給出Redis官方原話（結(jié)合前面最開始的Redis原話閱讀?。?/p>

但是jemalloc分配器非常智能，能夠重用空閑的內(nèi)存塊，因此在您釋放5GB數(shù)據(jù)集中的2GB后，當(dāng)您再次開始添加更多鍵時，您會看到RSS（駐留集大?。┍３址€(wěn)定，不會隨著您添加多達2GB的額外鍵而進一步增長。分配器基本上是試圖重用先前（邏輯上）釋放的 2GB 內(nèi)存。正因為如此，當(dāng)內(nèi)存使用量在峰值時遠大于當(dāng)前使用的內(nèi)存時，碎片率并不可靠。碎片率的計算方法是實際使用的物理內(nèi)存（RSS值）除以當(dāng)前使用的內(nèi)存量（Redis執(zhí)行的所有分配的總和）。
由于RSS 反映的是峰值內(nèi)存，因此當(dāng)（虛擬）使用的內(nèi)存較低（因為釋放了大量鍵/值）但RSS較高時，該比率將非常高RSS / mem_used。如果maxmemory沒有設(shè)置，Redis會繼續(xù)按其認為合適的方式分配內(nèi)存，因此它會（逐漸）耗盡所有可用內(nèi)存。因此，通常建議配置一些限制。

最佳實踐就是設(shè)置 maxmemory = 0.8*系統(tǒng)內(nèi)存，并且設(shè)置數(shù)據(jù)淘汰策略LRU算法來刪除部分key，釋放空間。最后，如果使用碎片整理，activefrag = yes CPU需要做出一定的讓步。慎重使用！

以上就是Redis關(guān)于內(nèi)存碎片的解決方法的詳細內(nèi)容，更多關(guān)于Redis內(nèi)存碎片解決的資料請關(guān)注腳本之家其它相關(guān)文章！

您可能感興趣的文章: