本文已收錄至Github,推薦閱讀 ?? Java隨想錄
微信公眾號:Java隨想錄
目錄- 記憶體碎片
- 記憶體碎片如何產生的?
- 記憶體分配器
- 怎么看是否有記憶體碎片?
- 碎片率的意義?
- 清理記憶體碎片
- 低于4.0-RC3版本的Redis
- 高于4.0-RC3版本的Redis
- Pipeline管道
- 為什么需要Pipeline
- 原生批命令(mset, mget)與Pipeline對比
- Pipeline的優缺點
- 一些疑問
- 相關代碼
記憶體碎片
記憶體碎片如何產生的?
Redis內部有自己的記憶體分配器,默認是jemalloc,為了提高記憶體使用的效率,來對記憶體的申請和釋放進行管理,
而記憶體分配器按照固定大小分配記憶體,并不是完全按照程式申請的記憶體大小來進行分配,
比如程式申請一個20位元組的記憶體,記憶體分配器會分配一個32位元組的記憶體空間,這么做是為了減少分配次數,redis會申請不同大小的記憶體空間來存盤不同業務不同型別的資料,由于記憶體按照固定大小分配且會比實際申請的記憶體要大一些,這個程序中會產生記憶體碎片,
舉個例子:
我們用高鐵車廂說明,假設一個車廂的座位總共有60個,現在已經賣 了57張票,需要三張連在一起的票,但發現買不到了,只好換一趟車,我們可以把這些分散的空座位叫作車廂座位碎片,
記憶體碎片類似上面高鐵座位的例子,雖然作業系統的剩余空間總量足夠,但申請一塊連續地址空間N位元組時,剩余記憶體空間中沒有大小為N位元組的連續空間,那么這些剩余空間就是記憶體碎片,
Redis的這種機制,提高了記憶體的使用率,但是會使Redis中有部分自己沒在用,卻不釋放的記憶體,導致了記憶體碎片的發生,
記憶體分配器
在編譯時指定的Redis使用的記憶體分配器,可以是libc、jemalloc、tcmalloc,默認是jemalloc,
jemalloc在64位系統中,將記憶體空間劃分為小、大、巨大三個范圍;每個范圍內又劃分了許多小的記憶體塊單位;存盤資料的時候,會選擇大小最合適的記憶體塊進行存盤,
jemalloc劃分的記憶體單元如下圖所示:
也就是說Redis是以指定大小的塊為單位進行連續記憶體分配的,而不是按需分配的,Redis 會根據申請的記憶體最接近的固定值分配相應大小的空間,
這就像你有不同的箱子,為了裝東西,你需要找一個體積最接近的箱子來裝,但是裝進去后,你發現還有空間可以放一些小東西,就無需再找箱子了,但是,這種分配空間的方式會帶來一定程度的記憶體碎片,我們可以把固定大小的劃分空間看成不同體積的箱子,每種箱子里的空間不同程度上都會有剩余,這些剩余的空間就是記憶體碎片,
怎么看是否有記憶體碎片?
我們登陸到Redis服務器上,執行以下命令:
redis> info memory
我們會看到這些資訊:
指標mem_fragmentation_ratio:1.86 表示當前的記憶體碎片率,
mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss:是Redis向作業系統申請的記憶體,
used_memory:是Redis中的資料占用的記憶體,
所以,mem_fragmentation_ratio=1應該是最理想的情況
碎片率的意義?
mem_fragmentation_ratio的不同值,說明不同的情況,
- 大于1:說明記憶體有碎片,一般在1到1.5之間是正常的,
- 大于1.5:說明記憶體碎片率比較大,需要考慮是否要進行記憶體碎片清理,要引起重視,
- 小于1:說明已經開始使用交換記憶體,也就是使用硬碟了,正常的記憶體不夠用了,需要考慮是否要進行記憶體的擴容,使用swap是相當影響性能的,
清理記憶體碎片
低于4.0-RC3版本的Redis
如果你的Redis版本是4.0-RC3以下的,Redis服務器重啟后,Redis會將沒用的記憶體歸還給作業系統,碎片率會降下來,
高于4.0-RC3版本的Redis
Redis4.0-RC3版本開始,可以在不重啟的情況下,線上整理記憶體碎片,
自動碎片清理,只要設定了如下的配置,記憶體就會自動清理了,
redis> config set activedefrag yes
自動清理記憶體碎片的功能需要該Redis的記憶體分配器是jemalloc時才能啟用,
啟用后需要同時滿足下面2個引數的設定條件時才會觸發自動清理
active-defrag-ignore-bytes 100mb # 默認100MB,表示記憶體碎片空間達到100MB時
active-defrag-threshold-lower 10 # 默認10,表示記憶體碎片空間占OS分配給redis的物理記憶體空間的比例達到10%時
redis是單行程模型,記憶體碎片自動清理是通過主執行緒操作的,也會消耗一定的CPU資源,為了避免自動清理降低Redis的處理性能,如下兩個引數可以控制清理動作消耗的CPU時間比例的上下限,
active-defrag-cycle-min 5 : 默認5,表示自動清理程序所用 CPU 時間的比例不低于5%,保證清理能正常開展;
active-defrag-cycle-max 75: 默認75,表示自動清理程序所用 CPU 時間的比例不高于 75%,一旦超過,就停止清理,從而避免在清理時,大量的記憶體拷貝阻塞 Redis,導致回應延遲升高,
如果你對自動清理的效果不滿意,可以使用如下命令,直接試下手動碎片清理:
redis > memory purge
需要注意的是,該清理命令也只當Redis的記憶體分配器是jemalloc時才能生效
#碎片整理總開關
activedefrag yes
#當碎片達到 100mb 時,開啟記憶體碎片整理
active-defrag-ignore-bytes 100mb
#當碎片超過 10% 時,開啟記憶體碎片整理
active-defrag-threshold-lower 10
#記憶體碎片超過 100%,則盡最大努力整理
active-defrag-threshold-upper 100
#記憶體自動整理占用資源最小百分比
active-defrag-cycle-min 5
#記憶體自動整理占用資源最大百分比
active-defrag-cycle-max 50
Pipeline管道
為什么需要Pipeline
Redis客戶端執行一條命令分4個程序:
發送命令-〉命令排隊-〉命令執行-〉回傳結果
這個程序稱為 Round Trip Time(簡稱RTT, 往返時間) ,mget mset有效節約了RTT,但大部分命令(如hgetall,并沒有mhgetall)不支持批量操作,需要消耗N次RTT ,這個時候需要Pipeline來解決這個問題
Pipeline 模式則是將執行的命令寫入到緩沖中,最后由exec命令一次性發送給Redis執行回傳,
1、未使用Pipeline執行N條命令
2、使用了Pipeline執行N條命令
原生批命令(mset, mget)與Pipeline對比
- 原生批命令是原子性,Pipeline是非原子性
- 原生批命令一命令多個key, 但Pipeline支持多命令,Pipeline 不支持事務,因為命令是一條一條執行的,
- 原生批命令是服務端實作,而Pipeline需要服務端與客戶端共同完成
Pipeline的優缺點
- pipeline 每批打包的命令不能過多,因為 Pipeline 方式打包命令再發送,那么 Redis 必須在處理完所有命令前先快取起所有命令的處理結果,這樣就有一個記憶體的消耗,
- Pipeline 操作是非原子性的,如果要求原子性的,不推薦使用 Pipeline
- 使用Pipeline組裝的命令個數不能太多,不然資料量過大,增加客戶端的等待時間,還可能造成網路阻塞,可以將大量命令的拆分多個小的pipeline命令完成,
一些疑問
Pipeline 執行多少命令合適?
根據官方的解釋,推薦是以 10k 每批 (注意:這個是一個參考值,請根據自身實際業務情況調整),
Pipeline 批量執行的時候,是否對Redis進行了鎖定,導致其他應用無法再進行讀寫?
Redis 采用多路I/O復用模型,非阻塞IO,所以Pipeline批量寫入的時候,一定范圍內不影響其他的讀操作,
在編碼時請注意,Pipeline 期間將“獨占”鏈接,此期間將不能進行非“管道”型別的其他操作,直到 Pipeline 關閉;如果你的 Pipeline 的指令集很龐大,為了不干擾鏈接中的其他操作,你可以為 Pipeline 操作新建 Client 鏈接,讓 Pipeline 和其他正常操作分離在2個 client 中,
相關代碼
@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;
});
}
本篇文章就到這里,感謝閱讀,如果本篇博客有任何錯誤和建議,歡迎給我留言指正,文章持續更新,可以關注公眾號第一時間閱讀,
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/547754.html
標籤:Java
上一篇:小白也讓你擁有一套屬于自己的chatgpt中文小程式
下一篇:布隆過濾器
