作者|萊烏
作為內存數據庫,內存內存空間大小對于 Redis 來說是然浪至關重要的。內存越多,費多意味著存儲的內存數據也會越多。但是然浪不知道你有沒有遇到過這樣的情況,明明空間很大,費多但是內存內存的使用卻不是很理想。
為什么會出現這樣的情況呢?這期我們就來看看這個"詭異"的事件。
坐好了,準備發車!
- 思維導圖?-
首先想要知道 Redis 內存的使用情況,我們就需要獲取相關的信息。
Redis 中查看內存相關信息是很簡單的,只需要在命令行輸入『info memory』就可以看到各種相關數據。在這里我羅列了一些較為重要的參數:
used_memory:已經使用了的內存大小。
used_memory_rss:redis 物理內存的大小。
mem_fragmentation_ratio:內存碎片率。
這里有一個內存碎片率的名詞需要關注下,它可以用來表示當前的內存使用情況。
具體計算方式:?
對于內存碎片率,一般保持在?1~1.5之間是最合理的。
了解了內存碎片率,那什么是內存碎片呢?
定義是這樣的:由于一塊連續空閑的空間比所要申請的空間小,導致這塊空間不可用,對于內存整體來說就是內存碎片。
舉個例子:
假設有一塊 100MB 的連續空閑內存空間,你每次都會從中申請一塊 30MB 的內存。那么當你申請了 3 次后,這塊內存就只剩下了 10MB 的空間,第 4 次申請的時候就會失敗。如果沒有其它的空間釋放并且每次申請的空間都比 10MB 大,那么剩下的空間對于整塊內存來說就是內存碎片。
Redis 中,最常用的是寫入、修改、刪除數據。這些操作在執行后都會產生 一定程度的內存碎片。
寫入數據
Redis 中分配內存是根據固定的大小來劃分內存空間的。為了減少分配次數,Redis 會根據申請的內存最接近的固定值分配相應大小的空間。
什么意思呢,假如 Redis 按照 8 字節、16 字節、32 字節、48 字節等來分配內存。當你想要存儲一個 18 字節的數據時,此時 Redis 就會分配 32 字節(因為 32 是與 18 最接近的固定值)。如果這時候,再寫入的數據需要的內存空間在 14 個字節內,那 Redis 就無需再進行分配了。
這就像你有不同的箱子,為了裝東西,你需要找一個體積最接近的箱子來裝。但是裝進去后,你發現還有空間可以放一些小東西,就無需再找箱子了。
但是,這種分配空間的方式會帶來一定程度的內存碎片。我們可以把固定大小的劃分空間看成不同體積的箱子,每種箱子里的空間不同程度上都會有剩余。這些剩余的空間就是內存碎片。
修改數據
鍵值對進行修改時,可能會變大也會變小,相應的就會占用額外空間或者釋放不用的空間。
如圖中所示,當前 A、B、C 分別占用了 3、2、4 個字節,將 A 從 3 字節修改為 2 字節時,此時就會有 1 個字節的空間空了出來,這時就會出現 1 個字節的碎片。
那如果我將數據 A 從 3 字節修改為 4 字節呢?此時為了保持數據 A 的空間連續性,操作系統會把 B 拷貝到別的空間。此時又會出現 1 個字節的碎片。
刪除數據
理解了修改數據,刪除數據就很容易明白了。還是上邊的例子,此時刪除了數據 B,那么就釋放了 2 個字節的空間。這樣對于整個內存空間來說就產生了 2 個字節的碎片。
你可能會有疑問,內存碎片會有什么危害呢?
我們還是以上邊的箱子來表示。你想想,如果你要把這些箱子都裝上車運走,每個箱子里都有空出來的空間(內存碎片),那么運行一次的效率及性價比是不是會很低。同樣,在 Redis 中,由于大量的碎片存在,會導致實際利用率變低。
那么我們有沒有辦法來解決內存碎片呢?
推倒重來
第一種方式很簡單,直接推倒重來。也就是把 Redis 直接重啟完事兒,內存一斷電全世界就清凈。但是這種暴力省事的方式卻有很多隱患。
生產環境中你這么搞的話得提前燒燒香,保佑不會出什么問題。如果你沒進行過持久化,那么就別燒了,燒了也沒用。如果有持久化的話,那么恢復時長還得取決你持久化文件的大小,在這個階段還無法提供服務。糟心不?
空間置換
那么有沒有不這么刺激的方式。
有的,高版本的 Redis 提供了內存碎片清理的方式。一言以蔽之,就是空間置換。
怎么個置換法?我們的目的是為了消除內存碎片,那么我們把已使用的內存數據重新整理到一起不就行了嗎?讓不連續的空間變成連續的,剩下的空間,繼續來分配。
畫個圖理解下:
但是,說說還是挺容易的,理論到實踐中間還隔著性能損耗。
在進行多次數據拷貝過程中,單線程的 Redis 只能干等著,無法響應客戶端的請求。這時候只能干瞪眼,性能太受影響。
涼,那該咋整?!別急,有緩解的策略,你接著往下看。
Redis 中有專門的參數設置用來進行自動清理內存碎片:activedefrag yes。
這個命令是啟動清理功能的,這還不夠,Redis 中還需要其他的條件限制才能夠進行清理。
下面參數都是滿足任一條件后就可以進行清理:
active-defrag-ignore-bytes 100mb:
碎片達到100MB時,開啟清理。
active-defrag-threshold-lower 10:
當碎片超過 10% 時,開啟清理。
active-defrag-threshold-upper 100:
內存碎片超過 100%,盡最大清理。
在處理的過程中,為了避免對正常請求的影響,同時又能保證性能。Redis 同時還提供了監控 CPU 占用比例的參數,在滿足以下條件時才會保證清理正常開展:
active-defrag-cycle-min 5:
active-defrag-cycle-max 75:
查看內存使用情況
在命令行執行 info memory 即可查看 Redis 內存相關信息。根據內存碎片率可以在一定時機內進行清理碎片清理。
內存碎片導致原因
寫入數據時,Redis 為了減少分配次數在分配內存是根據固定的大小來劃分內存空間的。修改數據時會釋放或占用額外的內存空間,刪除數據時會釋放空間。這樣就會產生不同程度的內存碎片。
如何解決內存碎片
通過重啟 Redis 的方式進行處理,如果沒有持久化可能會導致事故。在持久化情況下,恢復速度需要取決于文件的大小。
通過空間置換方式,也就是將已使用的內存數據重新整理到一起。
特別推薦一個分享架構+算法的優質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯系我們,謝謝!