詳細講解redis性能與監控方案

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

1、redis slowlog分析

SLOWLOG subcommand [argument]

以下為redis.conf的慢查詢配置參數：

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

以上參數可以在redis中動態查詢或設置：使用config get 與config set命令

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

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

重置slowlog統計數據：

SLOWLOG RESET

redis slow commands分析：

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

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

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

• SCAN迭代當前選定的Redis數據庫中的鍵集。

• SSCAN迭代sets集合類型的元素。

• HSCAN迭代哈希類型及其關聯值的字段。

• ZSCAN迭代排序集類型的元素及其相關聯的分數。

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

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

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

當游標設置為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選項：指定輸出的數量

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>參數

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*     #查找匹配的數據并返回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調用之后會產生大的延遲代價，以便在磁盤進行數據持久化。

可以使用這個方法關閉系統內核的該特性：

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

注：需重啟redis才能生效。

3、檢查redis是否受到系統使用swap的影響：

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

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

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

5、關于redis的延時監控框架

Redis latency monitoring framework

啟用redis監控框架的方法：

CONFIG SET latency-monitor-threshold 100

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

LATENCY命令的使用方法

查看最新的延時事件：

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

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

LATENCY HISTORY event-name

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

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

統計數據歸零：

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

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

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

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