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

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知識請關注PHP中文網redis教學欄位。

以上是redis效能分析與監控方案介紹的詳細內容。更多資訊請關注PHP中文網其他相關文章！