Redis服务信息--Info指令

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底层实现–字符串