一起聊聊Redis變慢的原因及檢驗方法

這篇文章為大家帶來了關於Redis的相關知識，其中主要介紹了關於Redis變慢的原因及排查方法的相關問題，下面一起來看一下，希望對大家有幫助。

推薦學習：Redis影片教學

#原因1：實例記憶體達到上限

排查想法

        如果你的Redis 實例設定了記憶體上限maxmemory，那麼也有可能導致Redis 變慢。

        當我們把 Redis 當做純快取使用時，通常會為這個實例設定一個記憶體上限 maxmemory，然後設定一個資料淘汰策略。而當實例的記憶體達到了 maxmemory 後，你可能會發現，在此之後每次寫入新數據，操作延遲變大了。

導致變慢的原因 

當Redis 記憶體達到maxmemory 後，每次寫入新的資料之前，Redis 必須先從實例中踢出一部分數據，讓整個實例的記憶體維持在maxmemory 之下，然後才能把新資料寫進來。

這個踢出舊資料的邏輯也是需要消耗時間的，而具體耗時的長短，要取決於你配置的淘汰策略：

• allkeys-lru：不管key是否設定了過期，淘汰最近最少訪問的key
• volatile-lru：只淘汰最近最少訪問、並設定了過期時間的key
• allkeys-random：不管key 是否設定了過期，隨機淘汰key
• volatile-random：只隨機淘汰設定了過期時間的key
• allkeys-ttl：不管key 是否設定了過期，淘汰即將過期的key
• noeviction：不淘汰任何key，實例記憶體達到maxmeory 後，再寫入新資料直接回傳錯誤
• allkeys-lfu：不管key 是否設定了過期，淘汰存取頻率最低的key（4.0 版本支援）
• volatile-lfu：只淘汰訪問頻率最低、並設定了過期時間key（4.0 版本支援）

        具體使用哪種策略，我們需要根據特定的業務場景來配置。一般最常使用的是allkeys-lru / volatile-lru 淘汰策略，它們的處理邏輯是，每次從實例中隨機取出一批key（這個數量可配置），然後淘汰一個最少訪問的key，之後把剩下的key 暫存到一個池子中，繼續隨機取一批key，並與先前池子中的key 比較，再淘汰一個最少訪問的key。以此往復，直到實例記憶體降到 maxmemory 之下。

        需要注意的是，Redis 的淘汰資料的邏輯與刪除過期key 的一樣，也是在命令真正執行之前執行的，也就是說它也會增加我們操作Redis 的延遲，而且，寫OPS越高，延遲也會越明顯。

另外，如果此時你的 Redis 實例中還儲存了 bigkey，那麼在淘汰刪除 bigkey 釋放記憶體時，也會耗時比較久。

看到了麼？ bigkey 的危害到處都是，這也是前面我提醒你盡量不儲存 bigkey 的原因。

解決方案

1. 避免儲存bigkey，降低釋放記憶體的耗時
2. 淘汰策略改為隨機淘汰，隨機淘汰比LRU要快很多（視業務狀況調整）
3. 分割實例，把淘汰key 的壓力分攤到多個實例上
4. 如果使用的是Redis 4.0 以上版本，開啟layz-free 機制，把淘汰key 釋放記憶體的操作放到後台執行緒執行（設定lazyfree-lazy-eviction = yes）

原因2：開啟記憶體大頁

#排查想法

• 我們都知道，應用程式向作業系統申請記憶體時，是按記憶體頁申請的，而常規的記憶體頁大小是4KB。
• Linux 核心從 2.6.38 開始，支援了記憶體大頁機制，該機制允許應用程式以 2MB 大小為單位，向作業系統申請記憶體。
• 應用程式每次向作業系統申請的記憶體單位變大了，但這也意味著申請記憶體的耗時變長。

導致變慢的原因

#

• 當 Redis 在執行後台 RDB 和 AOF rewrite 時，會採用 fork 子程序的方式來處理。但主進程 fork 子進程後，此時的主進程依舊是可以接收寫入請求的，而進來的寫入請求，會採用 Copy On Write（寫時複製）的方式操作記憶體資料。
• 也就是說，主程序一旦有數據需要修改，Redis 並不會直接修改現有記憶體中的數據，而是先將這塊記憶體資料拷貝出來，再修改這塊新記憶體的數據，這就是所謂的「寫時複製」。
• 寫時複製你也可以理解成，誰需要發生寫入操作，誰就需要先拷貝，再修改。
• 這樣做的好處是，父進程有任何寫入操作，並不會影響子進程的資料持久化（子進程只持久化fork 這一瞬間整個實例中的所有資料即可，不關心新的資料變更，因為子進程只需要一份記憶體快照，然後持久化到磁碟上）。
• 但是請注意，主進程在拷貝記憶體資料時，這個階段就涉及到新記憶體的申請，如果此時作業系統開啟了記憶體大頁，那麼在此期間，客戶端即便只修改10B 的數據，Redis 在申請記憶體時也會以2MB 為單位向作業系統申請，申請記憶體的耗時變長，進而導致每個寫入請求的延遲增加，影響到Redis 效能。
• 同樣地，如果這個寫請求操作的是一個 bigkey，那麼主程序在拷貝這個 bigkey 記憶體區塊時，一次申請的記憶體會更大，時間也會更久。可見，bigkey 在這裡又一次影響到了效能。

解決方案

#關閉記憶體大頁機制。

首先，你需要查看Redis 機器是否開啟了記憶體大頁：

$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

如果輸出選項是always，就表示目前開啟了記憶體大頁機制，我們需要關掉它：

$ echo never > /sys/kernel/mm/transparent_hugepage/enabled

其實，作業系統提供的記憶體大頁機制，其優點是，可以在一定程式上降低應用程式申請記憶體的次數。

但是對於 Redis 這種對效能和延遲極其敏感的資料庫來說，我們希望 Redis 在每次申請記憶體時，耗時盡量短，所以我不建議你在 Redis 機器上開啟這個機制。

原因3：使用Swap

檢查思路

#如果你發現Redis 突然變得非常慢，每次的操作耗時都達到了幾百毫秒甚至秒級，那此時你就需要檢查Redis 是否使用到了Swap，在這種情況下Redis 基本上已經無法提供高效能的服務了。

導致變慢的原因 

什麼是 Swap？為什麼使用 Swap 會導致 Redis 的效能下降？

如果你對作業系統有些了解，就會知道作業系統為了緩解記憶體不足對應用程式的影響，允許把一部分記憶體中的資料換到磁碟上，以達到應用程式對記憶體使用的緩衝，這些記憶體資料換到磁碟上的區域，就是Swap。

問題就在於，當記憶體中的資料換到磁碟上後，Redis 再存取這些資料時，就需要從磁碟上讀取，存取磁碟的速度要比存取記憶體慢幾百倍！尤其是針對 Redis 這種對效能要求極高、效能極為敏感的資料庫來說，這個操作延遲是無法接受的。

此時，你需要檢查 Redis 機器的記憶體使用情況，確認是否存在使用了 Swap。你可以透過以下方式來查看 Redis 進程是否使用到了 Swap：

# 先找到 Redis 的进程 ID
$ ps -aux | grep redis-server
 
# 查看 Redis Swap 使用情况
$ cat /proc/$pid/smaps | egrep '^(Swap|Size)'

輸出結果如下

Size:               1256 kB
Swap:                  0 kB
Size:                  4 kB
Swap:                  0 kB
Size:                132 kB
Swap:                  0 kB
Size:              63488 kB
Swap:                  0 kB
Size:                132 kB
Swap:                  0 kB
Size:              65404 kB
Swap:                  0 kB
Size:            1921024 kB
Swap:                  0 kB
...

        這個結果會列出 Redis 流程的記憶體使用量。

        每一行Size 表示Redis 所使用的一塊內存大小，Size 下面的Swap 就表示這塊Size 大小的內存，有多少資料已經被換到磁碟上了，如果這兩個值相等，說明這區塊記憶體的資料都已經完全被換到磁碟上了。

        如果只是少量資料被換到磁碟上，例如每一塊 Swap 佔對應 Size 的比例很小，那麼影響並不是很大。如果是幾百兆甚至上 GB 的記憶體被換到了磁碟上，那麼你就需要警惕了，這種情況 Redis 的效能肯定會急劇下降。

解決方案

1. 增加機器的內存，讓Redis 有足夠的記憶體可以使用
2. 整理記憶體空間，釋放出足夠的記憶體供Redis 使用，然後釋放Redis 的Swap，讓Redis 重新使用記憶體

        釋放Redis 的Swap 流程通常要重啟實例，為了避免重啟實例對業務的影響，一般會先進行主從切換，然後釋放舊主節點的Swap，重啟舊主節點實例，待從庫資料同步完成後，再進行主從切換即可。

        可見，並在 Redis 使用到 Swap 後，此時的 Redis 性能基本上已達不到高績效的要求（你可以理解為武功被廢），所以你也需要提前預防這種情況。

        預防的方法是，你需要對 Redis 機器的記憶體和 Swap 使用情況進行監控，在記憶體不足或使用到 Swap 時警出來，及時處理。

原因4：網路頻寬過載 

#檢查想法

        如果以上產生效能問題的場景，你都規避掉了，而且Redis 也穩定運行了很長一段時間，但在某個時間點之後開始，操作Redis 突然開始變慢了，而且一直持續下去，這種情況又是什麼原因導致？

        此時你需要排查 Redis 機器的網路頻寬是否過載，是否有某個執行個體把整台機器的網路頻寬佔滿的狀況。

導致變慢的原因

        網路頻寬過載的情況下，伺服器在 TCP 層和網路層就會出現封包發送延遲、遺失封包等情況。

        Redis 的高效能，除了操作記憶體之外，就在於網路 IO 了，如果網路 IO 有瓶頸，也會嚴重影響 Redis 的效能。

解決方案

1. 及時確認佔滿網路頻寬Redis 實例，如果屬於正常的業務訪問，那就需要及時擴容或遷移實例了，避免因為這個實例流量太大，影響這個機器的其他實例。
2. 維運層面，你需要對 Redis 機器的各項指標增加監控，包括網路流量，在網路流量達到一定閾值時提前報警，及時確認和擴容。

原因5：其他原因

##1) 頻繁短連結

        你的業務應用，應該使用長連結操作Redis，避免頻繁的短連接。

        頻繁的短連結會導致 Redis 大量時間耗費在連結的建立和釋放上，TCP 的三次握手和四次揮手同樣也會增加存取延遲。

2) 操作監控

        在前面也提到了，要先預知Redis 變慢的情況發生，不可或缺的就是做好完善的監控。

        監控其實就是對採集 Redis 的各項執行時間指標，通常的做法是監控程式定時採集 Redis 的 INFO 訊息，然後根據 INFO 訊息中的狀態資料做資料展示與警報。

        這裡我需要提醒你的是，在寫一些監控腳本，或使用開源的監控元件時，也不能掉以輕心。

        在寫入監控腳本存取 Redis 時，盡量採用長連結的方式擷取狀態訊息，避免頻繁短連結。同時，你也要注意控制存取 Redis 的頻率，避免影響到業務請求。

        在使用一些開源的監控元件時，最好了解這些元件的實作原理，以及正確配置這些元件，防止出現監控元件發生Bug，導致短時大量操作Redis，影響Redis 效能的狀況發生。

        我們當時就發生過，DBA 在使用一些開源元件時，因為設定和使用問題，導致監控程式頻繁地與 Redis 建立和斷開連接，導致 Redis 反應變慢。

3）其它程式爭搶資源

        最後一個需要提醒你的是，你的Redis 機器最好專項專用，只用來部署Redis 實例，不要部署其他應用程序，盡量給Redis 一個相對「安靜」的環境，避免其它程式佔用CPU、記憶體、磁碟資源，導致分配給Redis 的資源不足而受到影響。

推薦學習：

Redis影片教學

以上是一起聊聊Redis變慢的原因及檢驗方法的詳細內容。更多資訊請關注PHP中文網其他相關文章！