from：http://blog.csdn.net/dc_726/article/details/47699739
这篇关于redis监控的文章不错！（有一定的补充，另外标了颜色。）
Redis监控工具,命令和调优
1.图形化监控
因为要对Redis做性能测试，发现了GitHub上有个Python写的RedisLive监控工具评价不错。结果鼓捣了半天，最后发现其主页中引用了Google的jsapi脚本，必须在线连接谷歌的服务，Stackoverflow上说把js脚本下载到本地也没法解决问题，坑爹！正要放弃时发现了一个从RedisLive fork出去的项目redis-monitor，应该是国人改的吧，去掉了对谷歌jsapi的依赖，并完善了多Redis实例的管理，最终终于看到了久违的曲线图。
首先要保证安装了python。之后下载下列python包安装。可以手动下载tar.gz解压后执行python setup.py install逐一安装，或直接用pip下载：
- tornado：一个python的web框架
- redis.py：python的redis客户端
- python-dateutil
- backports.ssl_match_hostname
- argparse
- setuptools
- six
之后从GitHub上下载解压redis-monitor-master，修改src/redis_live.conf。必须配置一个单独的Redis实例存储监控数据，同时可以配置多个要监控的Redis实例。之后启动redis-monitor有些麻烦，需要启动两个前台进程和两个后台进程。
1.
粘贴过来的图：
Screenshot
2.命令行监控
前面可以看到，虽然图形化监控Redis比较美观、直接，但是安装起来比较麻烦。如果只是想简单看一下Redis的负载情况的话，完全可以用它提供的一些命令来完成。
2.1 吞吐量
Redis提供的INFO命令不仅能够查看实时的吞吐量(ops/sec)，还能看到一些有用的运行时信息。下面用grep过滤出一些比较重要的实时信息，比如已连接的和在阻塞的客户端、已用内存、拒绝连接、实时的tps和数据流量等。
2.2 延迟
2.2.1 客户端PING
从客户端可以监控Redis的延迟，利用Redis提供的PING命令，不断PING服务端，记录服务端响应PONG的时间。下面开两个终端，一个监控延迟，一个监视服务端收到的命令。
2.2.2 服务端内部机制
服务端内部的延迟监控稍微麻烦一些，因为延迟记录的默认阈值是0。尽管空间和时间耗费很小，Redis为了高性能还是默认关闭了它。所以首先我们要开启它，设置一个合理的阈值，例如下面命令中设置的100ms
CONFIG SET latency-monitor-threshold100
因为Redis执行命令非常快，所以我们用DEBUG命令人为制造一些慢执行命令：
debug sleep 2
下面就用LATENCY的各种子命令来查看延迟记录：
- LATEST：四列分别表示事件名、最近延迟的Unix时间戳、最近的延迟、最大延迟。
- HISTORY：延迟的时间序列。可用来产生图形化显示或报表。
- GRAPH：以图形化的方式显示。最下面以竖行显示的是指延迟在多久以前发生。
- RESET：清除延迟记录。
还有一个有趣的子命令DOCTOR，它能列出一些指导建议，例如开启慢日志进一步追查问题原因，查看是否有大对象被踢出或过期，以及操作系统的配置建议等。
2.2.3 度量延迟Baseline
延迟中的一部分是来自环境的，比如操作系统内核、虚拟化环境等等。Redis提供了让我们度量这一部分延迟基线(Baseline)的方法：
–intrinsic-latency后面是测试的时长(秒)，一般100秒足够了。
2.3 持续实时监控
Unix的WATCH命令是一个非常实用的工具，它可以实时监视任意命令的输出结果。比如上面我们提到的命令，稍加改造就能变成持续地实时监控工具。
2.4 慢操作日志
像SORT、LREM、SUNION等操作在大对象上会非常耗时，使用时要注意参照官方API上每个命令的算法复杂度。用前面介绍过的慢操作日志监控操作的执行时间。就像主流数据库提供的慢SQL日志一样，Redis也提供了记录慢操作的日志。注意这部分日志只会计算纯粹的操作耗时。
slowlog-log-slower-than设置慢操作的阈值，slowlog-max-len设置保存个数，因为慢操作日志与延迟记录一样，都是保存在内存中的。
3.官方优化建议
3.1 网络延迟
客户端可以通过TCP/IP或Unix域Socket连接到Redis。通常在千兆网络环境中，TCP/IP网络延迟是200us(微秒)，Unix域Socket可以低到30us。关于Unix域Socket(Unix Domain Socket)还是比较常用的技术，具体请参考Nginx+PHP-FPM的域Socket配置方法。
什么是域Socket？
维基百科：“Unix domain socket 或者 IPCsocket 是一种终端，可以使同一台操作系统上的两个或多个进程进行数据通信。与管道相比，Unix domain sockets 既可以使用字节流数和数据队列，而管道通信则只能通过字节流。U**nix domain sockets的接口和Internet socket很像，但它不使用网络底层协议来通信。Unix domain socket的功能是POSIX操作系统里的一种组件。Unix domain sockets使用系统文件的地址来作为自己的身份。它可以被系统进程引用。所以两个进程可以同时打开一个Unix domain sockets来进行通信。不过这种通信方式是发生在系统内核里而不会在网络里传播**。”
网络方面我们能做的就是减少在网络往返时间RTT(Round-Trip Time)。官方提供了以下一些建议：
- 长连接：不要频繁连接/断开到服务器的连接，尽可能保持长连接(Jedis现在就是这样做的)。
- 域Socket：如果客户端与Redis服务端在同一台机器上的话，使用Unix域Socket。
- 多参数命令：相比管道，优先使用多参数命令，如mset/mget/hmset/hmget等。
- 管道化：其次使用管道减少RTT。
- LUA脚本：对于有数据依赖而无法使用管道的命令，可以考虑在Redis服务端执行LUA脚本。
3.2 磁盘I/O
3.2.1 写磁盘
尽管Redis也是基于多路I/O复用的单线程机制，但是却没有像Nginx一样提供CPU Affinity的设置，避免fork出的子进程也跑在Redis主进程依附的CPU内核上，导致后台进程影响主进程。所以还是让操作系统自己去调度Redis主进程和后台进程吧。但反过来，如果不开启持久化机制的话，为Redis设置亲和性是否能进一步提升性能呢？
3.2.2 操作系统Swap
如果系统内存不足，可能会将Redis对应的某些页从内存swap到磁盘文件上。可以通过/proc文件夹中的smaps文件查看是否有数据页被swap。如果发现大量页被swap，则可以用vmstat和iostat进一步追查原因：
src/redis-cli -h 127.0.0.1 info | grep process_id
process_id:24191
cat /proc/24191/smaps | grep "Swap"
3.3 其他因素
3.3.1 Fork子进程
写RDB文件和rewrite AOF文件都需要fork出一个后台进程，fork操作的主要消耗在于页表的拷贝，不同系统的耗时会有些差异。其中，Xen问题比较严重。
3.3.2 Transparent Huge Page
此外，如果Linux开启了THP(Transparent Huge Page)功能的话，会极大地影响延迟。
3.3.3 Key过期
Redis同时使用主动和被动两种方式剔除已经过期的Key：
- 被动：当客户端访问到Key时，发现已经过期，则剔除
- 主动：每100ms剔除一批Key，假如过期Key超过25%则反复执行
所以，要避免同一时间超过25%的Key过期导致的Redis阻塞，设置过期时间时可以稍微随机化一些。
4.最后一招：WatchDog
官方说法提供的最后一招(last resort)就是WatchDog。它能够将慢操作的整个函数执行栈打印到Redis日志中。因为它与前面介绍过的将记录保存在内存中的延迟和满操作记录不同，所以记得使用前要在redis.conf中配置logfile日志路径：
src/redis-cli -h 127.0.0.1
CONFIG SET watchdog-period 500
附：参考资料
不得不说，Redis的官方文档写得非常不错！从中能学到很多不只是Redis，还有系统方面的知识。前面推荐大家仔细阅读官方网站上的每个主题。
from：http://www.cnblogs.com/kaituorensheng/p/3979298.html
本篇一般。
Redis介绍
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表、哈希、集合和有序集合5种。支持在服务器端计算集合的并、交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务器。Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
Redis监控
首先判断客户端和服务器连接是否正常
|
1
2
3
4
5
6
7
|
# 客户端和服务器连接正常，返回PONG
redis> PING
PONG
# 客户端和服务器连接不正常(网络不正常或服务器未能正常运行)，返回连接异常
redis
127.0
.
0.1:
6379
> PING
Could not connect to Redis at
127.0
.
0.1:
6379:
Connection refused
|
Redis 监控最直接的方法就是使用系统提供的 info 命令，只需要执行下面一条命令，就能获得 Redis 系统的状态报告。
|
1
|
redis-cli info
|
结果会返回 Server、Clients、Memory、Persistence、Stats、Replication、CPU、Keyspace 8个部分。从info大返回结果中提取相关信息，就可以达到有效监控的目的。
先解释下各个参数含义
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
# Server
redis_version:
2.8
.
8
# Redis 的版本
redis_git_sha
1:
00000000
redis_git_dirty:
0
redis_build_id:bf
5
d
1747
be
5380
f
redis_mode:standalone
os:Linux
2.6
.
32
-220.7
.
1
.el
6
.x
86
_
64
x
86
_
64
arch_bits:
64
multiplexing_api:epoll
gcc_version:
4.4
.
7
#gcc版本
process_id:
49324
# 当前 Redis 服务器进程id
run_id:bbd
7
b
17
efcf
108
fdde
285
d
8987
e
50392
f
6
a
38
f
48
tcp_port:
6379
uptime_in_seconds:
1739082
# 运行时间(秒)
uptime_in_days:
20
# 运行时间(天)
hz:
10
lru_clock:
1734729
config_file:/home/s/apps/RedisMulti_video_so/conf/zzz.conf
# Clients
connected_clients:
1
#连接的客户端数量
client_longest_output_list:
0
client_biggest_input_buf:
0
blocked_clients:
0
# Memory
used_memory:
821848
#Redis分配的内存总量
used_memory_human:
802.59
K
used_memory_rss:
85532672
#Redis分配的内存总量(包括内存碎片)
used_memory_peak:
178987632
used_memory_peak_human:
170.70
M #Redis所用内存的高峰值
used_memory_lua:
33792
mem_fragmentation_ratio:
104.07
#内存碎片比率
mem_allocator:tcmalloc
-2.0
# Persistence
loading:
0
rdb_changes_since_last_save:
0
#上次保存数据库之后，执行命令的次数
rdb_bgsave_in_progress:
0
#后台进行中的 save 操作的数量
rdb_last_save_time:
1410848505
#最后一次成功保存的时间点，以 UNIX 时间戳格式显示
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:
0
rdb_current_bgsave_time_sec:
-1
aof_enabled:
0
#redis是否开启了aof
aof_rewrite_in_progress:
0
aof_rewrite_scheduled:
0
aof_last_rewrite_time_sec:
-1
aof_current_rewrite_time_sec:
-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
# Stats
total_connections_received:
5705
#运行以来连接过的客户端的总数量
total_commands_processed:
204013
# 运行以来执行过的命令的总数量
instantaneous_ops_per_sec:
0
rejected_connections:
0
sync_full:
0
sync_partial_ok:
0
sync_partial_err:
0
expired_keys:
34401
#运行以来过期的 key 的数量
evicted_keys:
0
#运行以来删除过的key的数量
keyspace_hits:
2129
#命中key 的次数
keyspace_misses:
3148
#没命中key 的次数
pubsub_channels:
0
#当前使用中的频道数量
pubsub_patterns:
0
#当前使用中的模式数量
latest_fork_usec:
4391
# Replication
role:master #当前实例的角色master还是slave
connected_slaves:
0
master_repl_offset:
0
repl_backlog_active:
0
repl_backlog_size:
1048576
repl_backlog_first_byte_offset:
0
repl_backlog_histlen:
0
# CPU
used_cpu_sys:
1551.61
used_cpu_user:
1083.37
used_cpu_sys_children:
2.52
used_cpu_user_children:
16.79
# Keyspace
db
0:
keys=
3
,expires=
0
,avg_ttl=
0
#各个数据库的 key 的数量，以及带有生存期的 key 的数量
|
内存使用
如果 Redis 使用的内存超出了可用的物理内存大小，那么 Redis 很可能系统会被杀掉。针对这一点，你可以通过 info 命令对 used_memory 和 used_memory_peak 进行监控，为使用内存量设定阀值，并设定相应的报警机制。当然，报警只是手段，重要的是你得预先计划好，当内存使用量过大后，你应该做些什么，是清除一些没用的冷数据，还是把 Redis 迁移到更强大的机器上去。
持久化
如果因为你的机器或 Redis 本身的问题导致 Redis 崩溃了，那么你唯一的救命稻草可能就是 dump 出来的rdb文件了，所以，对 Redis dump 文件进行监控也是很重要的。可以通过对rdb_last_save_time 进行监控，了解最近一次 dump 数据操作的时间，还可以通过对rdb_changes_since_last_save进行监控来获得如果这时候出现故障，会丢失（即已改变）多少数据。
Keys
通过获取Keyspace中的结果得到各个数据库中key的数量
QPS
即每分钟执行的命令个数，即：(total_commands_processed2-total_commands_processed1)/span，为了实时得到QPS，可以设定脚本在后台运行，记录过去几分钟的total_commands_processed。在计算QPS时，利用过去的信息和当前的信息得出QPS的估计值。
参考
+
+
+
=
=
=
5394
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
