自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Redis數(shù)據(jù)已經(jīng)刪除了,為什么內(nèi)存占用還是很高?

數(shù)據(jù)庫(kù) Redis
對(duì)象占用的內(nèi)存是Redis中占用內(nèi)存最大的,這里存儲(chǔ)這我們的鍵值對(duì),我們知道不同的數(shù)據(jù)類型占用的內(nèi)存空間大小也不同,特別是那種大key占用內(nèi)存的情況就更驚人了。

前言

作為面試經(jīng)歷都很豐富的兄弟們,應(yīng)該或多或少被問(wèn)到或者自己親身經(jīng)歷過(guò)這個(gè)問(wèn)題,問(wèn)題如下:

?? Redis做了數(shù)據(jù)刪除操作,為什么使用top命令時(shí),還是顯示Redis占了很多內(nèi)存?

沒(méi)做相關(guān)功課的人覺(jué)得這個(gè)問(wèn)題有問(wèn)題,刪了數(shù)據(jù)還說(shuō)占著內(nèi)存,面試官不是在誤導(dǎo)我嗎,事實(shí)并非如此!

這里先說(shuō)答案 ????

?? 實(shí)際上,這是因?yàn)?,?dāng)數(shù)據(jù)刪除后,Redis 釋放的內(nèi)存空間會(huì)由內(nèi)存分配器管理,并不會(huì)立即返回給操作系統(tǒng)。所以,操作系統(tǒng)仍然會(huì)記錄著給 Redis 分配了大量?jī)?nèi)存。

而 used_memory_rss 記錄著在操作系統(tǒng)角度,Redis進(jìn)程占用的物理總內(nèi)存

這樣看來(lái)文章好像講完了,開頭就知道答案,當(dāng)然不是,內(nèi)容多著呢~

文章將從下面這些點(diǎn)分析擴(kuò)展你對(duì)于Redis內(nèi)存方面的知識(shí)點(diǎn),以及內(nèi)存碎片和如何清理內(nèi)存碎片。

畢竟面試官問(wèn)你一個(gè)問(wèn)題,你選擇只回答一句和面試官掰扯掰扯兩種方式,那么第二種情況更會(huì)讓他覺(jué)得你厲害爆了,懂得真多!??????

圖片圖片

Redis內(nèi)存消耗組成

Redis內(nèi)存消耗主要在于其主進(jìn)程消耗和子進(jìn)程消耗。而主進(jìn)程消耗又主要包括自身內(nèi)存、對(duì)象內(nèi)存、緩沖區(qū)內(nèi)存、內(nèi)存碎片四個(gè)方面:

圖片圖片

自身進(jìn)程占用內(nèi)存

Redis進(jìn)程自身所占用的內(nèi)存,這部分內(nèi)存通常很小,一個(gè)空的Redis進(jìn)程所消耗的內(nèi)存幾乎可以忽略不計(jì)

數(shù)據(jù)對(duì)象內(nèi)存

對(duì)象占用的內(nèi)存是Redis中占用內(nèi)存最大的,這里存儲(chǔ)這我們的鍵值對(duì),我們知道不同的數(shù)據(jù)類型占用的內(nèi)存空間大小也不同,特別是那種大key占用內(nèi)存的情況就更驚人了。

緩沖區(qū)

Redis主要有三大緩沖區(qū):客戶端緩沖區(qū)、AOF緩沖區(qū)、復(fù)制緩存區(qū)

圖片圖片

?? 客戶端緩沖區(qū): 為了解決客戶端和服務(wù)端請(qǐng)求和處理速度不匹配問(wèn)題(即CPU 與 I/O 設(shè)備速度不匹配的矛盾),分為輸入和輸出緩沖區(qū)。

輸入緩沖區(qū)會(huì)先把客戶端發(fā)送過(guò)來(lái)的命令暫存起來(lái),Redis 主線程再?gòu)妮斎刖彌_區(qū)中讀取命令,進(jìn)行處理。當(dāng)在處理完數(shù)據(jù)后,會(huì)把結(jié)果寫入到輸出緩沖區(qū),再通過(guò)輸出緩沖區(qū)返回給客戶端。

?? AOF緩沖區(qū): 在進(jìn)行AOF持久化時(shí)所用到的緩沖區(qū),AOF緩沖區(qū)消耗的內(nèi)存取決于AOF重寫時(shí)間和寫入命令量, 分為AOF緩沖區(qū)和AOF重寫緩沖區(qū)

?? 復(fù)制緩沖區(qū):是在集群環(huán)境中為了保證主從節(jié)點(diǎn)數(shù)據(jù)同步的所設(shè)置的,由于主從節(jié)點(diǎn)間的數(shù)據(jù)復(fù)制包括全量復(fù)制和增量復(fù)制兩種。因此復(fù)制緩沖區(qū)也分為復(fù)制緩沖區(qū)和復(fù)制積壓緩沖區(qū)兩種,分別用于全量和增量同步

內(nèi)存碎片

內(nèi)存碎片主要是有兩個(gè)原因:操作系統(tǒng)的內(nèi)存分配機(jī)制、Redis存儲(chǔ)特性,這兩個(gè)原因我們?cè)谖恼轮袝?huì)具體提到。

子進(jìn)程消耗

子進(jìn)程消耗是指在RDB、AOF重寫時(shí)fork()子進(jìn)程的內(nèi)存消耗

???? 有人說(shuō)這不是用到了寫時(shí)復(fù)制技術(shù)嗎?

?? 雖然子進(jìn)程可以不用完全復(fù)制父進(jìn)程的物理內(nèi)存,但是仍然需要復(fù)制其內(nèi)存頁(yè)表,在此期間如果有寫入操作則需要復(fù)制出一份副本出來(lái),因此同樣會(huì)消耗一部分內(nèi)存,消耗的內(nèi)存兩取決于RDB和AOF重寫期間的寫入命令數(shù)量。

查看內(nèi)存指標(biāo)

查看當(dāng)前Redis相關(guān)內(nèi)存信息用 info memory 命令,如果是集群使用 cluster info命令

127.0.0.1:6379> info memory
# Memory
used_memory:856472  // Redis 存儲(chǔ)數(shù)據(jù)占用的內(nèi)存量
used_memory_human:836.40K  // 人類可讀形式返回內(nèi)存總量
used_memory_rss:1282048  // 操作系統(tǒng)角度,進(jìn)程占用的物理總內(nèi)存
used_memory_rss_human:1.22M // used_memory_rss 可讀性模式展示
used_memory_peak:857448 // 內(nèi)存使用的最大值,表示 used_memory 的峰值
used_memory_peak_human:837.35K  // 以可讀的格式返回 used_memory_peak的值
used_memory_lua:37888   // Lua 引擎所消耗的內(nèi)存大小。
used_memory_lua_human:37.00K
maxmemory:2147483648    // 能使用的最大內(nèi)存值,字節(jié)為單位。
maxmemory_human:2.00G  // 可讀形式
maxmemory_policy:noeviction // 內(nèi)存淘汰策略

// used_memory_rss / used_memory 的比值,代表內(nèi)存碎片率
mem_fragmentation_ratio:2.79

used_memory_rss:操作系統(tǒng)分配給 Redis 進(jìn)程的內(nèi)存空間(包含內(nèi)存碎片占用的空間),此數(shù)據(jù)結(jié)果約等于top、ps命令看到的數(shù)據(jù)結(jié)果,是從操作系統(tǒng)層看到的數(shù)據(jù)

maxmemory:Redis 最大可用內(nèi)存,0表示不限制,我們一般會(huì)設(shè)置這個(gè)值,避免所有內(nèi)存超過(guò)物理內(nèi)存

內(nèi)存為何沒(méi)釋放

Redis 釋放的內(nèi)存空間會(huì)由內(nèi)存分配器管理,并不會(huì)立即返回給操作系統(tǒng),是因?yàn)椴捎昧艘环N稱為“惰性刪除”的機(jī)制,即在數(shù)據(jù)被刪除之后,并不會(huì)立即釋放內(nèi)存空間,而是等到有新數(shù)據(jù)需要使用該空間時(shí)才會(huì)釋放。

這種方式的好處是可以減少內(nèi)存分配和釋放的開銷,提高 Redis 的性能。

但是Redis釋放內(nèi)存空間可能不是連續(xù)的,可能導(dǎo)致空間閑置(也就是出現(xiàn)內(nèi)存碎片),而內(nèi)存碎片過(guò)大會(huì)導(dǎo)致明明有空間可用,但是卻無(wú)法存儲(chǔ)數(shù)據(jù)!

ok!我們繼續(xù)看看什么是內(nèi)存碎片

內(nèi)存碎片

前面我們已經(jīng)了解了Redis占用內(nèi)存的組成以及如何查看內(nèi)存占用信息,接下來(lái)看什么是內(nèi)存碎片和導(dǎo)致出現(xiàn)內(nèi)存碎片的原因。

Redis使用多種內(nèi)存分配策略,例如 jemalloc 和 libc,這些分配器無(wú)法做到按需分配,通常會(huì)按照固定大小進(jìn)行分配。例如,如果Redis申請(qǐng)6字節(jié)的內(nèi)存,操作系統(tǒng)會(huì)分配8字節(jié)的內(nèi)存給Redis使用,剩下的2個(gè)字節(jié)空間無(wú)法被使用就是內(nèi)存碎片。

但這種分配方式也有優(yōu)勢(shì),可以減少向操作系統(tǒng)申請(qǐng)空間分配。

導(dǎo)致Redis產(chǎn)生內(nèi)存碎片主要由以下兩點(diǎn):

  • ? 內(nèi)存分配機(jī)制導(dǎo)致
  • ? 數(shù)據(jù)修改引發(fā)空間擴(kuò)容和釋放

內(nèi)存分配機(jī)制導(dǎo)致

操作系統(tǒng)的架構(gòu)和 Redis jemalloc 分配策略無(wú)法做到按需分配,而是應(yīng)用程序申請(qǐng)內(nèi)存大小必須是一塊連續(xù)的內(nèi)存地址空間。

這種連續(xù)是按固定大小來(lái)分配的,比如:8字節(jié)、16 字節(jié)、32 字節(jié)、64 字節(jié) ... 這種方式會(huì)在程序申請(qǐng)內(nèi)存接近某個(gè)值的時(shí)候,jemalloc就會(huì)給它分配響應(yīng)大小的內(nèi)存空間。

圖片圖片

上圖中:

第一次存儲(chǔ)數(shù)據(jù)是需要6字節(jié),而Redis內(nèi)存分配策略給你分配了8字節(jié),空出2個(gè)字節(jié)的空間。

第二次存儲(chǔ)數(shù)據(jù)是需要4個(gè)字節(jié),但是空出的2個(gè)字節(jié)無(wú)法保存4字節(jié)數(shù)據(jù),所以會(huì)再次向系統(tǒng)申請(qǐng)8字節(jié)內(nèi)存空間,空出了4字節(jié),兩次存儲(chǔ)數(shù)據(jù)就多出來(lái)6個(gè)字節(jié)的內(nèi)存碎片。

這也就是內(nèi)存分配機(jī)制導(dǎo)致的形成碎片的風(fēng)險(xiǎn)和原因。

數(shù)據(jù)修改引發(fā)空間擴(kuò)容和釋放

這個(gè)原因應(yīng)該更好理解吧,若修改數(shù)據(jù)時(shí)占用的空間有變化,此時(shí)就需要擴(kuò)容或者縮容;而刪除數(shù)據(jù)也會(huì)將內(nèi)存釋放出來(lái),形成碎片。

如下圖:

圖片圖片

  • ? 各數(shù)據(jù)占用內(nèi)存字節(jié)空間分別是A:2、B:1、C:3、D:3
  • ? 此時(shí)D釋放了一個(gè)字節(jié)空間
  • ? A修改了數(shù)據(jù),增加了一個(gè)字節(jié)。為保證A的內(nèi)存空間連續(xù)性,B的數(shù)據(jù)拷貝到了第二階段D釋放出來(lái)的那個(gè)字節(jié)位置
  • ? C修改后刪除了2個(gè)字節(jié)空間

可以看出經(jīng)過(guò)一系列對(duì)數(shù)據(jù)的修改,C和D之間有2字段內(nèi)存空間,此時(shí)多出來(lái)2字節(jié)空間就是內(nèi)存碎片。

處理內(nèi)存碎片

如何在進(jìn)行處理內(nèi)存碎片,那么以什么為參考呢?

前面說(shuō)的 info memory命令,如果指標(biāo)值 mem_fragmentation_ratio (內(nèi)存碎片率)的值,在 1 < 碎片率 < 1.5,可以認(rèn)為是合理的,而大于 1.5 說(shuō)明碎片已經(jīng)超過(guò) 50%,我們需要采取一些手段解決碎片率過(guò)大的問(wèn)題。

有下面三種方式可處理 ??????:

圖片圖片

重啟Redis實(shí)例

重啟Redis屬于直接當(dāng)時(shí)粗暴的方式,在重啟之前要考慮兩點(diǎn):

  • ? 若Redis的數(shù)據(jù)沒(méi)有持久化,數(shù)據(jù)會(huì)丟失
  • ? 即使做了持久化,重啟需要通過(guò)AOF或RDB恢復(fù)數(shù)據(jù),恢復(fù)時(shí)間取決于日志的大小,如果恢復(fù)時(shí)間長(zhǎng),這個(gè)階段實(shí)例就不能提供服務(wù)了

這種方式還是要慎重!

memory purge手動(dòng)碎片整理

手動(dòng)整理內(nèi)存碎片,會(huì)阻塞主進(jìn)程,生產(chǎn)環(huán)境慎用。

memory purge 和 activedefrag回收的并不是同一塊區(qū)域的內(nèi)存,它簡(jiǎn)單粗暴的嘗試清除臟頁(yè)以便內(nèi)存分配器回收??梢愿鶕?jù)實(shí)際情況和activedefrag配合使用,memory purge在極端情況下效果較好,activedefrag則更徹底。

開啟activedefrag自動(dòng)碎片整理

在Redis 4.0 版本后新增配置項(xiàng)activedefrag,activedefrag默認(rèn)關(guān)閉,計(jì)劃清理碎片時(shí)需手動(dòng)開啟,命令如下:

127.0.0.1:6379> config set activedefrag yes

自動(dòng)整理內(nèi)存碎片,其原理是通過(guò)scan迭代整個(gè)Redis數(shù)據(jù),通過(guò)一系列的內(nèi)存復(fù)制、轉(zhuǎn)移操作完成內(nèi)存碎片整理,由于此操作使用的是主線程,故會(huì)影響Redis對(duì)其他請(qǐng)求的響應(yīng)。

圖片圖片

如上圖碎片整理過(guò)程:

1. 清理前,C和D之間多了2字節(jié)的內(nèi)存碎片

2. 清理過(guò)程:將B和D的數(shù)據(jù)分別拷貝到C和D之間的閑置空間,這樣2個(gè)字節(jié)的閑置空間就形成了連續(xù)空間。當(dāng)新應(yīng)用要申請(qǐng)小于3個(gè)字節(jié)的空間時(shí),這個(gè)閑置空間就能利用起來(lái)了

清理的條件

active-defrag-ignore-bytes 200mb:內(nèi)存碎片占用的內(nèi)存達(dá)到 200MB,開始清理;

active-defrag-threshold-lower 20:內(nèi)存碎片的空間占比超過(guò)系統(tǒng)分配給 Redis 空間的 20% ,開始清理

責(zé)任編輯:武曉燕 來(lái)源: 小許code
相關(guān)推薦

2024-12-23 15:28:01

2022-09-05 08:39:55

Redis存儲(chǔ)數(shù)據(jù)

2021-03-05 08:29:20

DeleteMysql數(shù)據(jù)結(jié)構(gòu)

2016-05-26 12:11:00

Redis內(nèi)存開源

2023-09-18 23:42:27

C++編程

2020-11-02 07:05:54

虛擬內(nèi)存Go

2022-04-14 08:21:35

數(shù)據(jù)庫(kù)查詢變慢MySQL

2020-09-04 09:58:58

Redis數(shù)據(jù)集群

2015-10-19 11:22:06

Edge瀏覽器微軟

2021-07-20 10:45:50

數(shù)據(jù)庫(kù)MySQLdelete

2023-03-21 08:02:36

Redis6.0IO多線程

2018-04-25 10:13:30

Redis內(nèi)存模型

2020-11-17 09:01:09

MySQLDelete數(shù)據(jù)

2011-07-05 08:38:56

數(shù)據(jù)庫(kù)采購(gòu)

2022-08-04 08:22:49

MySQL索引

2020-10-29 09:19:11

索引查詢存儲(chǔ)

2017-05-15 16:30:49

NoSQLMySQLOracle

2020-03-05 16:55:56

索引數(shù)據(jù)庫(kù)SQL

2014-11-18 10:36:36

互聯(lián)網(wǎng)

2021-07-30 06:49:40

SSD內(nèi)存CPU
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)