淺談Redis常見延遲問題定位與分析
使用復雜度高的命令
如果在使用Redis時,發現訪問延遲突然增大,如何進行排查?
首先,第一步,建議你去查看一下Redis的慢日志。Redis提供瞭慢日志命令的統計功能,我們通過以下設置,就可以查看有哪些命令在執行時延遲比較大。
首先設置Redis的慢日志閾值,隻有超過閾值的命令才會被記錄,這裡的單位是微妙,例如設置慢日志的閾值為5毫秒,同時設置隻保留最近1000條慢日志記錄:
# 命令執行超過5毫秒記錄慢日志 CONFIG SET slowlog-log-slower-than 5000 # 隻保留最近1000條慢日志 CONFIG SET slowlog-max-len 1000
設置完成之後,所有執行的命令如果延遲大於5毫秒,都會被Redis記錄下來,我們執行SLOWLOG get 5查詢最近5條慢日志:
127.0.0.1:6379> SLOWLOG get 5 1) 1) (integer) 32693 # 慢日志ID 2) (integer) 1593763337 # 執行時間 3) (integer) 5299 # 執行耗時(微妙) 4) 1) "LRANGE" # 具體執行的命令和參數 2) "user_list_2000" 3) "0" 4) "-1" 2) 1) (integer) 32692 2) (integer) 1593763337 3) (integer) 5044 4) 1) "GET" 2) "book_price_1000" ...
通過查看慢日志記錄,我們就可以知道在什麼時間執行哪些命令比較耗時,如果你的業務經常使用O(N)以上復雜度的命令,例如sort、sunion、zunionstore、keys、scan,或者在執行O(N)命令時操作的數據量比較大,這些情況下Redis處理數據時就會很耗時。
如果你的服務請求量並不大,但Redis實例的CPU使用率很高,很有可能是使用瞭復雜度高的命令導致的。
解決方案就是,不使用這些復雜度較高的命令,並且一次不要獲取太多的數據,每次盡量操作少量的數據,讓Redis可以及時處理返回。
存儲bigkey
如果查詢慢日志發現,並不是復雜度較高的命令導致的,例如都是SET、DELETE操作出現在慢日志記錄中,那麼你就要懷疑是否存在Redis寫入瞭bigkey的情況。
Redis在寫入數據時,需要為新的數據分配內存,當從Redis中刪除數據時,它會釋放對應的內存空間。
如果一個key寫入的數據非常大,Redis在分配內存時也會比較耗時。同樣的,當刪除這個key的數據時,釋放內存也會耗時比較久。
你需要檢查你的業務代碼,是否存在寫入bigkey的情況,需要評估寫入數據量的大小,業務層應該避免一個key存入過大的數據量。
針對bigkey的問題,Redis官方在4.0版本推出瞭lazy-free的機制,用於異步釋放bigkey的內存,降低對Redis性能的影響。即使這樣,我們也不建議使用bigkey,bigkey在集群的遷移過程中,也會影響到遷移的性能,這個後面在介紹集群相關的文章時,會再詳細介紹到。
集中過期
有時你會發現,平時在使用Redis時沒有延時比較大的情況,但在某個時間點突然出現一波延時,而且報慢的時間點很有規律,例如某個整點,或者間隔多久就會發生一次。
如果出現這種情況,就需要考慮是否存在大量key集中過期的情況。
如果有大量的key在某個固定時間點集中過期,在這個時間點訪問Redis時,就有可能導致延遲增加。
Redis的過期策略采用定期刪除+惰性刪除兩種策略;
註意,Redis的定期刪除的定時任務,也是在Redis主線程中執行的,也就是說如果在執行主動過期的過程中,出現瞭需要大量刪除過期key的情況,那麼在業務訪問時,必須等這個過期任務執行結束,才可以處理業務請求。此時就會出現,業務訪問延時增大的問題,最大延遲為25毫秒。
而且這個訪問延遲的情況,不會記錄在慢日志裡。慢日志中隻記錄真正執行某個命令的耗時,Redis主動過期策略執行在操作命令之前,如果操作命令耗時達不到慢日志閾值,它是不會計算在慢日志統計中的,但我們的業務卻感到瞭延遲增大。
解決方案是,在集中過期時增加一個隨機時間,把這些需要過期的key的時間打散即可。
實例內存達到上限
有時我們把Redis當做純緩存使用,就會給實例設置一個內存上限maxmemory,然後開啟LRU淘汰策略。
當實例的內存達到瞭maxmemory後,你會發現之後的每次寫入新的數據,有可能變慢瞭。
導致變慢的原因是,當Redis內存達到maxmemory後,每次寫入新的數據之前,必須先踢出一部分數據,讓內存維持在maxmemory之下。
這個踢出舊數據的邏輯也是需要消耗時間的,而具體耗時的長短,要取決於配置的淘汰策略
fork耗時嚴重
如果你的Redis開啟瞭自動生成RDB和AOF重寫功能,那麼有可能在後臺生成RDB和AOF重寫時導致Redis的訪問延遲增大,而等這些任務執行完畢後,延遲情況消失。
遇到這種情況,一般就是執行生成RDB和AOF重寫任務導致的。
生成RDB和AOF都需要父進程fork出一個子進程進行數據的持久化,在fork執行過程中,父進程需要拷貝內存頁表給子進程,如果整個實例內存占用很大,那麼需要拷貝的內存頁表會比較耗時,此過程會消耗大量的CPU資源,在完成fork之前,整個實例會被阻塞住,無法處理任何請求,如果此時CPU資源緊張,那麼fork的時間會更長,甚至達到秒級。這會嚴重影響Redis的性能。
綁定CPU
很多時候,我們在部署服務時,為瞭提高性能,降低程序在使用多個CPU時上下文切換的性能損耗,一般會采用進程綁定CPU的操作。
但在使用Redis時,我們不建議這麼幹,原因如下。
綁定CPU的Redis,在進行數據持久化時,fork出的子進程,子進程會繼承父進程的CPU使用偏好,而此時子進程會消耗大量的CPU資源進行數據持久化,子進程會與主進程發生CPU爭搶,這也會導致主進程的CPU資源不足訪問延遲增大。
所以在部署Redis進程時,如果需要開啟RDB和AOF重寫機制,一定不能進行CPU綁定操作
使用Swap
如果你發現Redis突然變得非常慢,每次訪問的耗時都達到瞭幾百毫秒甚至秒級,那此時就檢查Redis是否使用到瞭Swap,這種情況下Redis基本上已經無法提供高性能的服務。
我們知道,操作系統提供瞭Swap機制,目的是為瞭當內存不足時,可以把一部分內存中的數據換到磁盤上,以達到對內存使用的緩沖。
但當內存中的數據被換到磁盤上後,訪問這些數據就需要從磁盤中讀取,這個速度要比內存慢太多!
尤其是針對Redis這種高性能的內存數據庫來說,如果Redis中的內存被換到磁盤上,對於Redis這種性能極其敏感的數據庫,這個操作時間是無法接受的。可以臨時關閉操作系統Swap
網卡負載過高
特點就是從某個時間點之後就開始變慢,並且一直持續。這時你需要檢查一下機器的網卡流量,是否存在網卡流量被跑滿的情況。
網卡負載過高,在網絡層和TCP層就會出現數據發送延遲、數據丟包等情況。Redis的高性能除瞭內存之外,就在於網絡IO,請求量突增會導致網卡負載變高。
如果出現這種情況,你需要排查這個機器上的哪個Redis實例的流量過大占滿瞭網絡帶寬,然後確認流量突增是否屬於業務正常情況,如果屬於那就需要及時擴容或遷移實例,避免這個機器的其他實例受到影響。
到此這篇關於淺談Redis常見延遲問題定位與分析的文章就介紹到這瞭,更多相關Redis 延遲問題內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!