內(nèi)存碎片

內(nèi)存碎片如何產(chǎn)生的？

Redis內(nèi)部有自己的內(nèi)存分配器，默認(rèn)是jemalloc，為了提高內(nèi)存使用的效率，來(lái)對(duì)內(nèi)存的申請(qǐng)和釋放進(jìn)行管理。 而內(nèi)存分配器按照固定大小分配內(nèi)存，并不是完全按照程序申請(qǐng)的內(nèi)存大小來(lái)進(jìn)行分配。 比如程序申請(qǐng)一個(gè)20字節(jié)的內(nèi)存，內(nèi)存分配器會(huì)分配一個(gè)32字節(jié)的內(nèi)存空間，這么做是為了減少分配次數(shù)。redis會(huì)申請(qǐng)不同大小的內(nèi)存空間來(lái)存儲(chǔ)不同業(yè)務(wù)不同類型的數(shù)據(jù)，由于內(nèi)存按照固定大小分配且會(huì)比實(shí)際申請(qǐng)的內(nèi)存要大一些，這個(gè)過(guò)程中會(huì)產(chǎn)生內(nèi)存碎片。 舉個(gè)例子： 我們用高鐵車廂說(shuō)明，假設(shè)一個(gè)車廂的座位總共有60個(gè)，現(xiàn)在已經(jīng)賣 了57張票，需要三張連在一起的票，但發(fā)現(xiàn)買不到了，只好換一趟車。我們可以把這些分散的空座位叫作車廂座位碎片。

內(nèi)存碎片類似上面高鐵座位的例子。雖然操作系統(tǒng)的剩余空間總量足夠，但申請(qǐng)一塊連續(xù)地址空間N字節(jié)時(shí)，剩余內(nèi)存空間中沒(méi)有大小為N字節(jié)的連續(xù)空間，那么這些剩余空間就是內(nèi)存碎片。

Redis的這種機(jī)制，提高了內(nèi)存的使用率，但是會(huì)使Redis中有部分自己沒(méi)在用，卻不釋放的內(nèi)存，導(dǎo)致了內(nèi)存碎片的發(fā)生。

內(nèi)存分配器

在編譯時(shí)指定的Redis使用的內(nèi)存分配器，可以是libc、jemalloc、tcmalloc，默認(rèn)是jemalloc。

jemalloc在64位系統(tǒng)中，將內(nèi)存空間劃分為小、大、巨大三個(gè)范圍；每個(gè)范圍內(nèi)又劃分了許多小的內(nèi)存塊單位；存儲(chǔ)數(shù)據(jù)的時(shí)候，會(huì)選擇大小最合適的內(nèi)存塊進(jìn)行存儲(chǔ)。

jemalloc劃分的內(nèi)存單元如下圖所示：

也就是說(shuō)Redis是以指定大小的塊為單位進(jìn)行連續(xù)內(nèi)存分配的，而不是按需分配的。Redis 會(huì)根據(jù)申請(qǐng)的內(nèi)存最接近的固定值分配相應(yīng)大小的空間。

這就像你有不同的箱子，為了裝東西，你需要找一個(gè)體積最接近的箱子來(lái)裝。但是裝進(jìn)去后，你發(fā)現(xiàn)還有空間可以放一些小東西，就無(wú)需再找箱子了。但是，這種分配空間的方式會(huì)帶來(lái)一定程度的內(nèi)存碎片。我們可以把固定大小的劃分空間看成不同體積的箱子，每種箱子里的空間不同程度上都會(huì)有剩余。這些剩余的空間就是內(nèi)存碎片。

怎么看是否有內(nèi)存碎片？

我們登陸到Redis服務(wù)器上，執(zhí)行以下命令：

redis> info memory

我們會(huì)看到這些信息：

指標(biāo)mem_fragmentation_ratio:1.86 表示當(dāng)前的內(nèi)存碎片率。

mem_fragmentation_ratio = used_memory_rss / used_memory

used_memory_rss：是Redis向操作系統(tǒng)申請(qǐng)的內(nèi)存。 used_memory：是Redis中的數(shù)據(jù)占用的內(nèi)存。

所以，mem_fragmentation_ratio=1應(yīng)該是最理想的情況

碎片率的意義？

mem_fragmentation_ratio的不同值，說(shuō)明不同的情況。

• 大于1：說(shuō)明內(nèi)存有碎片，一般在1到1.5之間是正常的。
• 大于1.5：說(shuō)明內(nèi)存碎片率比較大，需要考慮是否要進(jìn)行內(nèi)存碎片清理，要引起重視。
• 小于1：說(shuō)明已經(jīng)開始使用交換內(nèi)存，也就是使用硬盤了，正常的內(nèi)存不夠用了，需要考慮是否要進(jìn)行內(nèi)存的擴(kuò)容，使用swap是相當(dāng)影響性能的。

清理內(nèi)存碎片

低于4.0-RC3版本的Redis

如果你的Redis版本是4.0-RC3以下的，Redis服務(wù)器重啟后，Redis會(huì)將沒(méi)用的內(nèi)存歸還給操作系統(tǒng)，碎片率會(huì)降下來(lái)。

高于4.0-RC3版本的Redis

Redis4.0-RC3版本開始，可以在不重啟的情況下，線上整理內(nèi)存碎片。 自動(dòng)碎片清理，只要設(shè)置了如下的配置，內(nèi)存就會(huì)自動(dòng)清理了。

redis> config set activedefrag yes 

自動(dòng)清理內(nèi)存碎片的功能需要該Redis的內(nèi)存分配器是jemalloc時(shí)才能啟用。

啟用后需要同時(shí)滿足下面2個(gè)參數(shù)的設(shè)置條件時(shí)才會(huì)觸發(fā)自動(dòng)清理

active-defrag-ignore-bytes 100mb    # 默認(rèn)100MB,表示內(nèi)存碎片空間達(dá)到100MB時(shí)
active-defrag-threshold-lower 10    # 默認(rèn)10，表示內(nèi)存碎片空間占OS分配給redis的物理內(nèi)存空間的比例達(dá)到10%時(shí)

redis是單進(jìn)程模型，內(nèi)存碎片自動(dòng)清理是通過(guò)主線程操作的，也會(huì)消耗一定的CPU資源。為了避免自動(dòng)清理降低Redis的處理性能，如下兩個(gè)參數(shù)可以控制清理動(dòng)作消耗的CPU時(shí)間比例的上下限。

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

如果你對(duì)自動(dòng)清理的效果不滿意，可以使用如下命令，直接試下手動(dòng)碎片清理：

redis > memory purge

需要注意的是，該清理命令也只當(dāng)Redis的內(nèi)存分配器是jemalloc時(shí)才能生效

#碎片整理總開關(guān)
activedefrag yes
 
#當(dāng)碎片達(dá)到 100mb 時(shí)，開啟內(nèi)存碎片整理
active-defrag-ignore-bytes 100mb
 
#當(dāng)碎片超過(guò) 10% 時(shí)，開啟內(nèi)存碎片整理
active-defrag-threshold-lower 10
 
#內(nèi)存碎片超過(guò) 100%，則盡最大努力整理
active-defrag-threshold-upper 100
 
#內(nèi)存自動(dòng)整理占用資源最小百分比
active-defrag-cycle-min 5
 
#內(nèi)存自動(dòng)整理占用資源最大百分比
active-defrag-cycle-max 50

Pipeline管道

為什么需要Pipeline

Redis客戶端執(zhí)行一條命令分4個(gè)過(guò)程：

發(fā)送命令－〉命令排隊(duì)－〉命令執(zhí)行－〉返回結(jié)果

這個(gè)過(guò)程稱為 Round Trip Time(簡(jiǎn)稱RTT, 往返時(shí)間) ，mget mset有效節(jié)約了RTT，但大部分命令（如hgetall，并沒(méi)有mhgetall）不支持批量操作，需要消耗N次RTT ，這個(gè)時(shí)候需要Pipeline來(lái)解決這個(gè)問(wèn)題

Pipeline 模式則是將執(zhí)行的命令寫入到緩沖中，最后由exec命令一次性發(fā)送給Redis執(zhí)行返回。

1、未使用Pipeline執(zhí)行N條命令

2、使用了Pipeline執(zhí)行N條命令

原生批命令(mset, mget)與Pipeline對(duì)比

• 原生批命令是原子性，Pipeline是非原子性
• 原生批命令一命令多個(gè)key, 但Pipeline支持多命令，Pipeline 不支持事務(wù)，因?yàn)槊钍且粭l一條執(zhí)行的。
• 原生批命令是服務(wù)端實(shí)現(xiàn)，而Pipeline需要服務(wù)端與客戶端共同完成

Pipeline的優(yōu)缺點(diǎn)

• pipeline 每批打包的命令不能過(guò)多，因?yàn)?Pipeline 方式打包命令再發(fā)送，那么 Redis 必須在處理完所有命令前先緩存起所有命令的處理結(jié)果。這樣就有一個(gè)內(nèi)存的消耗。
• Pipeline 操作是非原子性的，如果要求原子性的，不推薦使用 Pipeline
• 使用Pipeline組裝的命令個(gè)數(shù)不能太多，不然數(shù)據(jù)量過(guò)大，增加客戶端的等待時(shí)間，還可能造成網(wǎng)絡(luò)阻塞，可以將大量命令的拆分多個(gè)小的pipeline命令完成。

一些疑問(wèn)

Pipeline 執(zhí)行多少命令合適？

根據(jù)官方的解釋，推薦是以 10k 每批 (注意：這個(gè)是一個(gè)參考值，請(qǐng)根據(jù)自身實(shí)際業(yè)務(wù)情況調(diào)整)。

Pipeline 批量執(zhí)行的時(shí)候，是否對(duì)Redis進(jìn)行了鎖定，導(dǎo)致其他應(yīng)用無(wú)法再進(jìn)行讀寫？

Redis 采用多路I/O復(fù)用模型，非阻塞IO，所以Pipeline批量寫入的時(shí)候，一定范圍內(nèi)不影響其他的讀操作。

在編碼時(shí)請(qǐng)注意，Pipeline 期間將“獨(dú)占”鏈接，此期間將不能進(jìn)行非“管道”類型的其他操作，直到 Pipeline 關(guān)閉；如果你的 Pipeline 的指令集很龐大，為了不干擾鏈接中的其他操作，你可以為 Pipeline 操作新建 Client 鏈接，讓 Pipeline 和其他正常操作分離在2個(gè) client 中。

相關(guān)代碼

    @Test
    void pipeline() {
        List<Object> result = redisTemplate.executePipelined((RedisCallback<String>) connection -> {
            for (int i = 0; i < 100; i++) {
                redisTemplate.opsForValue().set("pipel:" + i, i);
            }
            return null;
        });
    }

以上就是Redis內(nèi)存碎片產(chǎn)生原因及Pipeline管道原理解析的詳細(xì)內(nèi)容，更多關(guān)于Redis內(nèi)存碎片Pipeline管道的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論