详细讲解redis性能与监控方案

这篇文章主要为大家详细介绍了redis性能与监控方案，文中示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下。

我们提供的服务有：成都网站制作、成都做网站、外贸营销网站建设、微信公众号开发、网站优化、网站认证、尧都ssl等。为1000多家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的尧都网站制作公司

详细讲解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性能与监控方案就分享到这里了，当然并不止以上和大家分析的办法，不过小编可以保证其准确性是绝对没问题的。希望以上内容可以对大家有一定的参考价值，可以学以致用。如果喜欢本篇文章，不妨把它分享出去让更多的人看到。

当前文章：详细讲解redis性能与监控方案
分享URL：http://cqcxhl.com/article/piciii.html

重庆分公司，新征程启航

详细讲解redis性能与监控方案

其他资讯