使用復(fù)雜度高的命令

如果在使用Redis時(shí)，發(fā)現(xiàn)訪問(wèn)延遲突然增大，如何進(jìn)行排查？

首先，第一步，建議你去查看一下Redis的慢日志。Redis提供了慢日志命令的統(tǒng)計(jì)功能，我們通過(guò)以下設(shè)置，就可以查看有哪些命令在執(zhí)行時(shí)延遲比較大。

首先設(shè)置Redis的慢日志閾值，只有超過(guò)閾值的命令才會(huì)被記錄，這里的單位是微妙，例如設(shè)置慢日志的閾值為5毫秒，同時(shí)設(shè)置只保留最近1000條慢日志記錄：

# 命令執(zhí)行超過(guò)5毫秒記錄慢日志
CONFIG SET slowlog-log-slower-than 5000
# 只保留最近1000條慢日志
CONFIG SET slowlog-max-len 1000

設(shè)置完成之后，所有執(zhí)行的命令如果延遲大于5毫秒，都會(huì)被Redis記錄下來(lái)，我們執(zhí)行SLOWLOG get 5查詢(xún)最近5條慢日志：

127.0.0.1:6379> SLOWLOG get 5
1) 1) (integer) 32693       # 慢日志ID
   2) (integer) 1593763337  # 執(zhí)行時(shí)間
   3) (integer) 5299        # 執(zhí)行耗時(shí)(微妙)
   4) 1) "LRANGE"           # 具體執(zhí)行的命令和參數(shù)
      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"
...

通過(guò)查看慢日志記錄，我們就可以知道在什么時(shí)間執(zhí)行哪些命令比較耗時(shí)，如果你的業(yè)務(wù)經(jīng)常使用O(N)以上復(fù)雜度的命令，例如sort、sunion、zunionstore、keys、scan，或者在執(zhí)行O(N)命令時(shí)操作的數(shù)據(jù)量比較大，這些情況下Redis處理數(shù)據(jù)時(shí)就會(huì)很耗時(shí)。

如果你的服務(wù)請(qǐng)求量并不大，但Redis實(shí)例的CPU使用率很高，很有可能是使用了復(fù)雜度高的命令導(dǎo)致的。

解決方案就是，不使用這些復(fù)雜度較高的命令，并且一次不要獲取太多的數(shù)據(jù)，每次盡量操作少量的數(shù)據(jù)，讓Redis可以及時(shí)處理返回。

存儲(chǔ)bigkey

如果查詢(xún)慢日志發(fā)現(xiàn)，并不是復(fù)雜度較高的命令導(dǎo)致的，例如都是SET、DELETE操作出現(xiàn)在慢日志記錄中，那么你就要懷疑是否存在Redis寫(xiě)入了bigkey的情況。

Redis在寫(xiě)入數(shù)據(jù)時(shí)，需要為新的數(shù)據(jù)分配內(nèi)存，當(dāng)從Redis中刪除數(shù)據(jù)時(shí)，它會(huì)釋放對(duì)應(yīng)的內(nèi)存空間。

如果一個(gè)key寫(xiě)入的數(shù)據(jù)非常大，Redis在分配內(nèi)存時(shí)也會(huì)比較耗時(shí)。同樣的，當(dāng)刪除這個(gè)key的數(shù)據(jù)時(shí)，釋放內(nèi)存也會(huì)耗時(shí)比較久。

你需要檢查你的業(yè)務(wù)代碼，是否存在寫(xiě)入bigkey的情況，需要評(píng)估寫(xiě)入數(shù)據(jù)量的大小，業(yè)務(wù)層應(yīng)該避免一個(gè)key存入過(guò)大的數(shù)據(jù)量。

針對(duì)bigkey的問(wèn)題，Redis官方在4.0版本推出了lazy-free的機(jī)制，用于異步釋放bigkey的內(nèi)存，降低對(duì)Redis性能的影響。即使這樣，我們也不建議使用bigkey，bigkey在集群的遷移過(guò)程中，也會(huì)影響到遷移的性能，這個(gè)后面在介紹集群相關(guān)的文章時(shí)，會(huì)再詳細(xì)介紹到。

集中過(guò)期

有時(shí)你會(huì)發(fā)現(xiàn)，平時(shí)在使用Redis時(shí)沒(méi)有延時(shí)比較大的情況，但在某個(gè)時(shí)間點(diǎn)突然出現(xiàn)一波延時(shí)，而且報(bào)慢的時(shí)間點(diǎn)很有規(guī)律，例如某個(gè)整點(diǎn)，或者間隔多久就會(huì)發(fā)生一次。

如果出現(xiàn)這種情況，就需要考慮是否存在大量key集中過(guò)期的情況。

如果有大量的key在某個(gè)固定時(shí)間點(diǎn)集中過(guò)期，在這個(gè)時(shí)間點(diǎn)訪問(wèn)Redis時(shí)，就有可能導(dǎo)致延遲增加。

Redis的過(guò)期策略采用定期刪除+惰性刪除兩種策略；

注意，Redis的定期刪除的定時(shí)任務(wù)，也是在Redis主線(xiàn)程中執(zhí)行的，也就是說(shuō)如果在執(zhí)行主動(dòng)過(guò)期的過(guò)程中，出現(xiàn)了需要大量刪除過(guò)期key的情況，那么在業(yè)務(wù)訪問(wèn)時(shí)，必須等這個(gè)過(guò)期任務(wù)執(zhí)行結(jié)束，才可以處理業(yè)務(wù)請(qǐng)求。此時(shí)就會(huì)出現(xiàn)，業(yè)務(wù)訪問(wèn)延時(shí)增大的問(wèn)題，最大延遲為25毫秒。

而且這個(gè)訪問(wèn)延遲的情況，不會(huì)記錄在慢日志里。慢日志中只記錄真正執(zhí)行某個(gè)命令的耗時(shí)，Redis主動(dòng)過(guò)期策略執(zhí)行在操作命令之前，如果操作命令耗時(shí)達(dá)不到慢日志閾值，它是不會(huì)計(jì)算在慢日志統(tǒng)計(jì)中的，但我們的業(yè)務(wù)卻感到了延遲增大。

解決方案是，在集中過(guò)期時(shí)增加一個(gè)隨機(jī)時(shí)間，把這些需要過(guò)期的key的時(shí)間打散即可。

實(shí)例內(nèi)存達(dá)到上限

有時(shí)我們把Redis當(dāng)做純緩存使用，就會(huì)給實(shí)例設(shè)置一個(gè)內(nèi)存上限maxmemory，然后開(kāi)啟LRU淘汰策略。

當(dāng)實(shí)例的內(nèi)存達(dá)到了maxmemory后，你會(huì)發(fā)現(xiàn)之后的每次寫(xiě)入新的數(shù)據(jù)，有可能變慢了。

導(dǎo)致變慢的原因是，當(dāng)Redis內(nèi)存達(dá)到maxmemory后，每次寫(xiě)入新的數(shù)據(jù)之前，必須先踢出一部分?jǐn)?shù)據(jù)，讓內(nèi)存維持在maxmemory之下。

這個(gè)踢出舊數(shù)據(jù)的邏輯也是需要消耗時(shí)間的，而具體耗時(shí)的長(zhǎng)短，要取決于配置的淘汰策略

fork耗時(shí)嚴(yán)重

如果你的Redis開(kāi)啟了自動(dòng)生成RDB和AOF重寫(xiě)功能，那么有可能在后臺(tái)生成RDB和AOF重寫(xiě)時(shí)導(dǎo)致Redis的訪問(wèn)延遲增大，而等這些任務(wù)執(zhí)行完畢后，延遲情況消失。

遇到這種情況，一般就是執(zhí)行生成RDB和AOF重寫(xiě)任務(wù)導(dǎo)致的。

生成RDB和AOF都需要父進(jìn)程fork出一個(gè)子進(jìn)程進(jìn)行數(shù)據(jù)的持久化，在fork執(zhí)行過(guò)程中，父進(jìn)程需要拷貝內(nèi)存頁(yè)表給子進(jìn)程，如果整個(gè)實(shí)例內(nèi)存占用很大，那么需要拷貝的內(nèi)存頁(yè)表會(huì)比較耗時(shí)，此過(guò)程會(huì)消耗大量的CPU資源，在完成fork之前，整個(gè)實(shí)例會(huì)被阻塞住，無(wú)法處理任何請(qǐng)求，如果此時(shí)CPU資源緊張，那么fork的時(shí)間會(huì)更長(zhǎng)，甚至達(dá)到秒級(jí)。這會(huì)嚴(yán)重影響Redis的性能。

綁定CPU

很多時(shí)候，我們?cè)诓渴鸱?wù)時(shí)，為了提高性能，降低程序在使用多個(gè)CPU時(shí)上下文切換的性能損耗，一般會(huì)采用進(jìn)程綁定CPU的操作。

但在使用Redis時(shí)，我們不建議這么干，原因如下。

綁定CPU的Redis，在進(jìn)行數(shù)據(jù)持久化時(shí)，fork出的子進(jìn)程，子進(jìn)程會(huì)繼承父進(jìn)程的CPU使用偏好，而此時(shí)子進(jìn)程會(huì)消耗大量的CPU資源進(jìn)行數(shù)據(jù)持久化，子進(jìn)程會(huì)與主進(jìn)程發(fā)生CPU爭(zhēng)搶?zhuān)@也會(huì)導(dǎo)致主進(jìn)程的CPU資源不足訪問(wèn)延遲增大。

所以在部署Redis進(jìn)程時(shí)，如果需要開(kāi)啟RDB和AOF重寫(xiě)機(jī)制，一定不能進(jìn)行CPU綁定操作

使用Swap

如果你發(fā)現(xiàn)Redis突然變得非常慢，每次訪問(wèn)的耗時(shí)都達(dá)到了幾百毫秒甚至秒級(jí)，那此時(shí)就檢查Redis是否使用到了Swap，這種情況下Redis基本上已經(jīng)無(wú)法提供高性能的服務(wù)。

我們知道，操作系統(tǒng)提供了Swap機(jī)制，目的是為了當(dāng)內(nèi)存不足時(shí)，可以把一部分內(nèi)存中的數(shù)據(jù)換到磁盤(pán)上，以達(dá)到對(duì)內(nèi)存使用的緩沖。

但當(dāng)內(nèi)存中的數(shù)據(jù)被換到磁盤(pán)上后，訪問(wèn)這些數(shù)據(jù)就需要從磁盤(pán)中讀取，這個(gè)速度要比內(nèi)存慢太多！

尤其是針對(duì)Redis這種高性能的內(nèi)存數(shù)據(jù)庫(kù)來(lái)說(shuō)，如果Redis中的內(nèi)存被換到磁盤(pán)上，對(duì)于Redis這種性能極其敏感的數(shù)據(jù)庫(kù)，這個(gè)操作時(shí)間是無(wú)法接受的?？梢耘R時(shí)關(guān)閉操作系統(tǒng)Swap

網(wǎng)卡負(fù)載過(guò)高

特點(diǎn)就是從某個(gè)時(shí)間點(diǎn)之后就開(kāi)始變慢，并且一直持續(xù)。這時(shí)你需要檢查一下機(jī)器的網(wǎng)卡流量，是否存在網(wǎng)卡流量被跑滿(mǎn)的情況。

網(wǎng)卡負(fù)載過(guò)高，在網(wǎng)絡(luò)層和TCP層就會(huì)出現(xiàn)數(shù)據(jù)發(fā)送延遲、數(shù)據(jù)丟包等情況。Redis的高性能除了內(nèi)存之外，就在于網(wǎng)絡(luò)IO，請(qǐng)求量突增會(huì)導(dǎo)致網(wǎng)卡負(fù)載變高。

如果出現(xiàn)這種情況，你需要排查這個(gè)機(jī)器上的哪個(gè)Redis實(shí)例的流量過(guò)大占滿(mǎn)了網(wǎng)絡(luò)帶寬，然后確認(rèn)流量突增是否屬于業(yè)務(wù)正常情況，如果屬于那就需要及時(shí)擴(kuò)容或遷移實(shí)例，避免這個(gè)機(jī)器的其他實(shí)例受到影響。

到此這篇關(guān)于淺談Redis常見(jiàn)延遲問(wèn)題定位與分析的文章就介紹到這了,更多相關(guān)Redis 延遲問(wèn)題內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論