詳細講解redis性能與監(jiān)控方案

發(fā)布時間：2020-04-09 11:06:35 來源：億速云閱讀：436 作者：小新欄目：關系型數(shù)據庫

這篇文章主要為大家詳細介紹了redis性能與監(jiān)控方案，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下。

1、redis slowlog分析

SLOWLOG subcommand [argument]

以下為redis.conf的慢查詢配置參數(shù)：

slowlog-log-slower-than 10000     #查詢時間超過10ms的會被記錄
slowlog-max-len 128     #最多記錄128個慢查詢

以上參數(shù)可以在redis中動態(tài)查詢或設置：使用config get 與config set命令

讀取慢查詢：可以獲取指定幾條的慢查詢

127.0.0.1:6320> slowlog get 1
 1) 1) (integer) 394689     #slowlog的唯一編號
    2) (integer) 1480851711     #此次slowlog事件的發(fā)生時間
    3) (integer) 10639     #耗時
    4) 1) "HGET"     #slowlog事件所對應的redis 命令
       2) "hash:submit_sent_150004"
       3) "15000429648122734363745165312"

重置slowlog統(tǒng)計數(shù)據：

SLOWLOG RESET

redis slow commands分析：

1、redis使用單線程處理客戶端的請求，結果是，當請求緩慢服務時，所有其他客戶端將等待這個請求被服務。如果需要執(zhí)行很多的slow commands，建議把slow queries放到redis slave上去執(zhí)行。

2、關于keys命令：執(zhí)行慢速命令所產生的非常常見的延遲源是在生產環(huán)境中使用KEYS命令。如Redis文檔中所述，KEYS應該只用于調試目的。

redis2.8以后為查詢大集合而引入了新的命令，請檢查SCAN，SSCAN，HSCAN和ZSCAN命令以獲取更多信息。

SCAN迭代當前選定的Redis數(shù)據庫中的鍵集。
SSCAN迭代sets集合類型的元素。
HSCAN迭代哈希類型及其關聯(lián)值的字段。
ZSCAN迭代排序集類型的元素及其相關聯(lián)的分數(shù)。

由于這些命令允許增量迭代，每次調用僅返回少量元素，所以它們可以在生產中使用，而無需像KEYS或SMEMBERS這樣的命令的缺點，當調用大集合的鍵或元素時可能會阻止服務器長時間（甚至幾秒鐘）。

2、SCAN，SSCAN，HSCAN和ZSCAN命令的使用方法

SCAN是基于游標的迭代器。這意味著在每次調用命令時，服務器返回一個更新的游標，用戶需要在下一次調用中用作游標參數(shù)。

當游標設置為0時，迭代開始，并且當服務器返回的游標為0時終止迭代。以下是SCAN迭代的示例：

127.0.0.1:6319> scan 0
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 65536
1) "884736"
2)  1) "list:submit_sent_2016-12-01-17:55_175010"
    2) "list:submit_sent_2016-12-02-18:28_138052"
    3) "list:submit_sent_2016-12-01-18:17_150243"
    4) "list:submit_sent_2016-12-01-11:22_137606"
    5) "list:submit_sent_2016-12-01-21:15_183748"
    6) "list:submit_sent_2016-12-02-11:47_155212"
    7) "list:submit_sent_2016-12-01-11:01_137065"
    8) "list:submit_sent_2016-12-02-08:03_181202"
    9) "list:submit_sent_2016-12-02-12:16_136096"
   10) "list:submit_sent_2016-12-01-18:12_159893"

開始游標值為0的迭代，并調用SCAN，直到返回的游標再次為0，稱為完全迭代。

scan的count選項：指定輸出的數(shù)量

127.0.0.1:6319> scan 0 count 20
1) "884736"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"
   16) "list:submit_sent_2016-12-02-11:47_155212"
   17) "list:submit_sent_2016-12-01-11:01_137065"
   18) "list:submit_sent_2016-12-02-08:03_181202"
   19) "list:submit_sent_2016-12-02-12:16_136096"
   20) "list:submit_sent_2016-12-01-18:12_159893"

scan的match選項：類似于keys命令按模式匹配，只需在SCAN命令末尾附加MATCH <pattern>參數(shù)

127.0.0.1:6319> scan 0 match *submit_sent*
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 0 count 15  match *submit_sent*     #查找匹配的數(shù)據并返回15個
1) "2031616"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"

sscan查詢sets集合的方法：

redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood
(integer) 6
redis 127.0.0.1:6379> sscan myset 0 match f*
1) "0"
2) 1) "foo"
   2) "feelsgood"
   3) "foobar"
redis 127.0.0.1:6379>

hscan查詢hash集合的方法：

redis 127.0.0.1:6379> hmset hash name Jack age 33
OK
redis 127.0.0.1:6379> hscan hash 0
1) "0"
2) 1) "name"
   2) "Jack"
   3) "age"
   4) "33"

當一個Linux內核啟用了透明巨頁功能時，Redis在使用fork調用之后會產生大的延遲代價，以便在磁盤進行數(shù)據持久化。

可以使用這個方法關閉系統(tǒng)內核的該特性：

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

注：需重啟redis才能生效。

3、檢查redis是否受到系統(tǒng)使用swap的影響：

查找redis進程id：
redis-cli -p 6319 info|grep process_id
process_id:32139
查看redis進程的內存使用信息：
cd /proc/32139
查看該進程使用swap分區(qū)的統(tǒng)計信息，以不使用或只有少量的4kB為佳：
cat smaps | grep 'Swap:'
同時打印出內存映射和swap使用信息：查看那些較大的內存消耗是否引發(fā)了大的swap使用
cat smaps | egrep '^(Swap:Size)'

4、使用redis watchdog定位延時：實驗功能，請確保redis數(shù)據已備份。

Redis software watchdog
該功能只能動態(tài)啟用，使用以下命令：
CONFIG SET watchdog-period 500
注：redis會開始頻繁監(jiān)控自身的延時問題，并把問題輸出到日志文件中去。
 
關閉watchdog：
CONFIG SET watchdog-period 0
 
注：打開watchdog功能，會對redis服務性能產生影響。

5、關于redis的延時監(jiān)控框架

Redis latency monitoring framework

啟用redis監(jiān)控框架的方法：

CONFIG SET latency-monitor-threshold 100

默認情況下，閾值設置為0，即禁用redis監(jiān)控。實際上啟用該監(jiān)控功能，對redis所增加的成本很少。不過對于一個運行良好的redis，是沒有必要打開該監(jiān)控功能。

LATENCY命令的使用方法

查看最新的延時事件：

127.0.0.1:6319> latency latest
1) 1) "command"     #event name
   2) (integer) 1480865648     #發(fā)生時間
   3) (integer) 207     #耗時，毫秒
   4) (integer) 239     #從redis啟動或上次latency reset以來，這種事件的最大延時記錄

查看延時事件的歷史信息：

LATENCY HISTORY event-name

對于給定事件，命令將返回最多160個元素。應用程序可能想要獲取原始數(shù)據以便執(zhí)行監(jiān)視，顯示圖形等。

127.0.0.1:6319> latency history command
  1) 1) (integer) 1480865710
     2) (integer) 207
  2) 1) (integer) 1480865711
     2) (integer) 217
  3) 1) (integer) 1480865712
     2) (integer) 198
  4) 1) (integer) 1480865713
     2) (integer) 226
  5) 1) (integer) 1480865714
     2) (integer) 224

統(tǒng)計數(shù)據歸零：

LATENCY RESET [event-name ... event-name]

以文本圖表形式展示延時事件：

LATENCY GRAPH event-name
127.0.0.1:6379> latency graph command
command - high 500 ms, low 101 ms (all time high 500 ms)
--------------------------------------------------------------------------------
   #_
  _||
 _|||
_||||
 
11186
542ss
sss

注：每一列表示一個遲時事件；下方顯示的是該事件發(fā)生在當前時間之前多久，如2m或38s；統(tǒng)計事件中最小延時事件記為一個短下劃線，最大延時事件表示為高高在上的一個#。該圖可以體現(xiàn)出延時事件的一個變化趨勢。

LATENCY DOCTOR，延時事件統(tǒng)計信息的智能分析與建議：

127.0.0.1:6379> latency doctor
Dave, I have observed latency spikes in this Redis instance.
You don't mind talking about it, do you Dave?
1. command: 5 latency spikes (average 300ms, mean deviation 120ms,
  period 73.40 sec). Worst all time event 500ms.
I have a few advices for you:
- Your current Slow Log configuration only logs events that are
  slower than your configured latency monitor threshold. Please
  use 'CONFIG SET slowlog-log-slower-than 1000'.
- Check your Slow Log to understand what are the commands you are
  running which are too slow to execute. Please check
  http://redis.io/commands/slowlog for more information.
- Deleting, expiring or evicting (becaus

127.0.0.1:6320> latency doctor
I have a few advices for you:
- I detected a non zero amount of anonymous huge pages used by your process. This creates very serious latency events in different conditions, especially 
when Redis is persisting on disk. To disable THP support use the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled', make sure to also 
add it into /etc/rc.local so that the command will be executed again after a reboot. Note that even if you have already disabled THP, you still need to
 restart the Redis process to get rid of the huge pages already created.

關于redis性能與監(jiān)控方案就分享到這里了，當然并不止以上和大家分析的辦法，不過小編可以保證其準確性是絕對沒問題的。希望以上內容可以對大家有一定的參考價值，可以學以致用。如果喜歡本篇文章，不妨把它分享出去讓更多的人看到。

向AI問一下細節(jié)

詳細講解redis性能與監(jiān)控方案

猜你喜歡

最新資訊

相關推薦

相關標簽