Redis服务信息–Info指令
- 在使用Redis时候,可能会遇到一些异常情况,我们排查完代码问题后,会需要对Redis进行排查,在对Redis错误进行排查之前,需要了解Redis运行状态,通过强大Info指令,可以清晰的知道Redis内部的一些运行参数。
- Info指令的信息是最全面的,分为如下9大块,每一块信息都有非常多的参数,如下:
- Server:服务器运行环境参数
- Clients:客户端相关信息
- Memory:服务器运行内存统计数据
- Persistence:持久化信息
- Stats:通用统计数据
- Replication:主从复制相关信息
- CPU:CPU使用情况
- Cluster:集群信息
- KeySpace:键值对统计数量信息
- 以下介绍我认为对排查问题关键的一些内容。
Redis每秒执行次数指令
- info stats中,可以看到每秒操作指令次数:
新docker-redis:0>info stats
"# Stats
total_connections_received:97290
total_commands_processed:106600526
instantaneous_ops_per_sec:732
- 以上 instantaneous_ops_per_sec:732,也就是所有客户端一起,每秒发送732 条指令到服务器执行。极限情况下,Redis可以10W/s的指令,测试环境我们可以通过monitor指令观看观察一下那些key被访问的比较频繁,从而在相应的业务上进行优化。以减少IO操作次数。
Redis客户端连接数
- 这部分信息在Clients块中,通过info clients看到:
新docker-redis:0>info clients
"# Clients
connected_clients:141
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
"
- 以上信息也是比较重要的信息, connected_clients 标识正在连接的客户端数量 141 个,可以通过这个看出是否有意料之外的连接。如果发现数量不对劲,可以使用client list指令列出所有客户端连接地址来确定源头:
新docker-redis:0>client list
"id=97758 addr=172.0.0.1:39086 fd=131 name= age=108 idle=108 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=get
......
- 与客户端连接相关的参数还有另外一个比较重要:rejected_connections,标识因为超出最大连接数限制而被拒绝的客户端连接的次数。如果这个数值很大,意味着我们的Redis服务无法承载限制的访问量,需要调节连接数的最大值,maxclients参数:
新docker-redis:0>info stats
"# Stats
......
instantaneous_output_kbps:190.50
rejected_connections:0
......
Redis内存占用
- 这块信息是经常需查询的信息,可以通过info memory看到
新docker-redis:0>info memory
"# Memory
used_memory:8575938024
used_memory_human:7.99G //内存分配器(jmealloc)从操作系统分配的内存总量 7.99G
used_memory_rss:10298728448
used_memory_rss_human:9.59G //操作系统看到的内存占用,top命令看到的内存
used_memory_peak:8590183584
used_memory_peak_human:8.00G //Redis内存消耗的峰值
used_memory_peak_perc:99.83% //Redis内存消耗峰值占比总内存大小
......
复制积压缓冲区的大小
- 这个信息在Replication块里,可以通过info replication看到
新docker-redis:0>info replication
"# Replication
role:master
connected_slaves:0
master_replid:cf472bcc723376a795b764b7496308068e661bda
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576 //积压缓冲区大小 1048576 字节
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
"
-
复制挤压缓冲区大小非常重要,严重影响主从复制的效率。当从节点因为网络原因临时断开了对主节点的复制,然后网络恢复且又重新链接上,这期间发送在主节点是的修改指令都会被放再积压缓冲区中,这样从节点可以通过积压缓冲区恢复中断的主从同步过程。
-
上一节主从同步中我们也讨论过环形缓冲区问题,从节点端口时间过长,或者缓冲区设置太小,都会导致从节点无法快速恢复中断,因为积压缓冲区环形存储满之后会被之后的指令覆盖,这时候只能全量同步,非常耗资源
-
应该有一个适当的大小,当有多个从节点复制,积压缓冲区是共享的,不会因为从节点格式线性增加
-
如果实例修改指令请求频繁,应该调大积压缓冲区 几十MB差不多
-
Redis闲置的时候,即MB即可
-
可以通过sync_artial_err参数的次数来决定是否需要扩大积压缓冲区,他标识主从同步复制失败的次数。
新docker-redis:0>info stats
"# Stats
......
sync_full:0
sync_partial_ok:0
sync_partial_err:0 //同步失败次数 0
......
上一篇:Redis高可用基石–主从同步
下一篇:Redis底层实现–字符串