敗家玩意兒!Redis 居然浪費了這麼多內存!

做爲內存數據庫,內存空間大小對於 Redis 來講是相當重要的。內存越多,意味着存儲的數據也會越多。可是不知道你有沒有遇到過這樣的狀況,明明空間很大,可是內存的使用卻不是很理想。redis

爲何會出現這樣的狀況呢?這期咱們就來看看這個"詭異"的事件。數據庫

坐好了,準備發車!性能

圖注:思惟導圖spa

查看內存使用狀況

首先想要知道 Redis 內存的使用狀況,咱們就須要獲取相關的信息。操作系統

Redis 中查看內存相關信息是很簡單的,只須要在命令行輸入『info memory』就能夠看到各類相關數據。在這裏我羅列了一些較爲重要的參數:命令行

  • used_memory:已經使用了的內存大小。線程

  • used_memory_rss:redis 物理內存的大小。3d

  • mem_fragmentation_ratio:內存碎片率。blog

這裏有一個內存碎片率的名詞須要關注下,它能夠用來表示當前的內存使用狀況。事件

具體計算方式: 

對於內存碎片率,通常保持在 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 分別佔用了 三、二、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:清理內存碎片佔用 CPU 時間的比例不低於此值,保證清理能正常開展。

  • active-defrag-cycle-max 75:清理內存碎片佔用 CPU 時間的比例不高於此值。一旦超過則中止清理,從而避免在清理時,大量的內存拷貝阻塞 Redis,致使其它請求延遲。

總結

查看內存使用狀況

  • 在命令行執行 info memory 便可查看 Redis 內存相關信息。根據內存碎片率能夠在必定時機內進行清理碎片清理。

內存碎片致使緣由

  • 寫入數據時,Redis 爲了減小分配次數在分配內存是根據固定的大小來劃份內存空間的。修改數據時會釋放或佔用額外的內存空間,刪除數據時會釋放空間。這樣就會產生不一樣程度的內存碎片。 

如何解決內存碎片

  • 經過重啓 Redis 的方式進行處理,若是沒有持久化可能會致使事故。在持久化狀況下,恢復速度須要取決於文件的大小。

  • 經過空間置換方式,也就是將已使用的內存數據從新整理到一塊兒。

關於做者

做者:你們好,我是萊烏,BAT搬磚工一枚。從小公司進入大廠,一路走來收穫良多,想將這些經驗分享給有須要的人,所以建立了公衆號「IT界農民工」。定時更新,但願能幫助到你。

相關文章
相關標籤/搜索