Redis Info 命令

Redis Info 命令以一种易于理解和阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。

通过给定可选的参数 section ，可以让命令只返回某一部分的信息：

server : 一般 Redis 服务器信息，包含以下域：
- redis_version : Redis 服务器版本
- redis_git_sha1 : Git SHA1
- redis_git_dirty : Git dirty flag
- os : Redis 服务器的宿主操作系统
- arch_bits : 架构（32 或 64 位）
- multiplexing_api : Redis 所使用的事件处理机制
- gcc_version : 编译 Redis 时所使用的 GCC 版本
- process_id : 服务器进程的 PID
- run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）
- tcp_port : TCP/IP 监听端口
- uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数
- uptime_in_days : 自 Redis 服务器启动以来，经过的天数
- lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理
clients : 已连接客户端信息，包含以下域：
- connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
- client_longest_output_list : 当前连接的客户端当中，最长的输出列表
- client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
- blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
memory : 内存信息，包含以下域：
- used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位
- used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
- used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
- used_memory_peak : Redis 的内存消耗峰值（以字节为单位）
- used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
- used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）
- mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
- mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。

当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。

内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。

当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。

当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。

如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。

查看 used_memory_peak 的值可以验证这种情况是否发生。
persistence : RDB 和 AOF 的相关信息
stats : 一般统计信息
replication : 主/从复制信息
cpu : CPU 计算量统计信息
commandstats : Redis 命令统计信息
cluster : Redis 集群信息
keyspace : 数据库相关的统计信息

# Server
redis_version:5.0.8
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:f5de7c59791f2d0a
redis_mode:standalone
os:Linux 3.10.0-1062.18.1.el7.x86_64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:8.3.0
process_id:1
run_id:0af71da428854489e825ed709a3abe82af43c60d
tcp_port:6379
uptime_in_seconds:558729
uptime_in_days:6
hz:10
configured_hz:10
lru_clock:10464552
executable:/data/redis-server
config_file:

# Clients
connected_clients:3
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory
used_memory:898560
used_memory_human:877.50K
used_memory_rss:12513280
used_memory_rss_human:11.93M
used_memory_peak:4998384
used_memory_peak_human:4.77M
used_memory_peak_perc:17.98%
used_memory_overhead:877034
used_memory_startup:791264
used_memory_dataset:21526
used_memory_dataset_perc:20.06%
allocator_allocated:1158176
allocator_active:1409024
allocator_resident:8511488
total_system_memory:3973369856
total_system_memory_human:3.70G
used_memory_lua:66560
used_memory_lua_human:65.00K
used_memory_scripts:2160
used_memory_scripts_human:2.11K
number_of_cached_scripts:6
maxmemory:0
maxmemory_human:0B
maxmemory_policy:noeviction
allocator_frag_ratio:1.22
allocator_frag_bytes:250848
allocator_rss_ratio:6.04
allocator_rss_bytes:7102464
rss_overhead_ratio:1.47
rss_overhead_bytes:4001792
mem_fragmentation_ratio:14.61
mem_fragmentation_bytes:11656720
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:83538
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1587046539
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:6402048
aof_enabled:0
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
aof_last_cow_size:0

# Stats
total_connections_received:88
total_commands_processed:238
instantaneous_ops_per_sec:0
total_net_input_bytes:67596
total_net_output_bytes:148055
instantaneous_input_kbps:0.00
instantaneous_output_kbps:0.00
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:3
expired_stale_perc:0.00
expired_time_cap_reached_count:0
evicted_keys:0
keyspace_hits:21
keyspace_misses:39
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:1220
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# Replication
role:master
connected_slaves:0
master_replid:f3f5c1ebf085e9a74a401b88efdb18bd89848233
master_replid2:91f3e9b0b11bc5f4083e846a1399174e86933f92
master_repl_offset:0
second_repl_offset:1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

# CPU
used_cpu_sys:869.539401
used_cpu_user:895.500259
used_cpu_sys_children:0.053327
used_cpu_user_children:0.365536

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=1,expires=0,avg_ttl=0
127.0.0.1:6379>

当然也可以获取单个的信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:0
master_replid:f3f5c1ebf085e9a74a401b88efdb18bd89848233
master_replid2:91f3e9b0b11bc5f4083e846a1399174e86933f92
master_repl_offset:0
second_repl_offset:1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>

Redis 每秒执行多少次指令

root@d4cad7fb69c2:/data# redis-cli info stats |grep ops
instantaneous_ops_per_sec:789
root@d4cad7fb69c2:/data#

以上，表示 ops 是 789，也就是所有客户端每秒会发送 789 条指令到服务器执行。极限情况下，Redis 可以每秒执行 10w 次指令，CPU 几乎完全榨干。如果 qps 过高，可以考
虑通过 monitor 指令快速观察一下究竟是哪些 key 访问比较频繁，从而在相应的业务上进行优化，以减少 IO 次数。monitor 指令会瞬间吐出来巨量的指令文本，所以一般在执行
monitor 后立即 ctrl+c 中断输出。

root@d4cad7fb69c2:/data#  redis-cli monitor
OK
^Z
[1]+  Stopped                 redis-cli monitor
root@d4cad7fb69c2:/data#

Redis 连接了多少客户端？
这个信息在 Clients 块里，可以通过 info clients 看到。

root@d4cad7fb69c2:/data# redis-cli info clients
# Clients
connected_clients:4
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0
root@d4cad7fb69c2:/data#

这个信息也是比较有用的，通过观察这个数量可以确定是否存在意料之外的连接。如果
发现这个数量不对劲，接着就可以使用 client list 指令列出所有的客户端链接地址来确定源头。

关于客户端的数量还有个重要的参数需要观察，那就是 rejected_connections，它表示因
为超出最大连接数限制而被拒绝的客户端连接次数，如果这个数字很大，意味着服务器的最
大连接数设置的过低需要调整 maxclients 参数。

root@d4cad7fb69c2:/data# redis-cli info stats |grep reject
rejected_connections:0
root@d4cad7fb69c2:/data#

Redis 内存占用多大 ?

这个信息在 Memory 块里，可以通过 info memory 看到。

root@d4cad7fb69c2:/data# redis-cli info memory | grep used | grep human
used_memory_human:897.02K  # 内存分配器 (jemalloc) 从操作系统分配的内存总量
used_memory_rss_human:11.93M  # 操作系统看到的内存占用 ,top 命令看到的内存
used_memory_peak_human:4.77M  # Redis 内存消耗的峰值
used_memory_lua_human:65.00K  # lua 脚本引擎占用的内存大小
used_memory_scripts_human:2.11K
root@d4cad7fb69c2:/data#

如果单个 Redis 内存占用过大，并且在业务上没有太多压缩的空间的话，可以考虑集群化了。

复制积压缓冲区多大?

这个信息在 Replication 块里，可以通过 info replication 看到。

root@d4cad7fb69c2:/data# redis-cli info replication |grep backlog
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
root@d4cad7fb69c2:/data#

复制积压缓冲区大小非常重要，它严重影响到主从复制的效率。当从库因为网络原因临时断开了主库的复制，然后网络恢复了，又重新连上的时候，这段断开的时间内发生在
master 上的修改操作指令都会放在积压缓冲区中，这样从库可以通过积压缓冲区恢复中断的主从同步过程。

积压缓冲区是环形的，后来的指令会覆盖掉前面的内容。如果从库断开的时间过长，或者缓冲区的大小设置的太小，都会导致从库无法快速恢复中断的主从同步过程，因为中间的
修改指令被覆盖掉了。这时候从库就会进行全量同步模式，非常耗费 CPU 和网络资源。如果有多个从库复制，积压缓冲区是共享的，它不会因为从库过多而线性增长。如果实
例的修改指令请求很频繁，那就把积压缓冲区调大一些，几十个 M 大小差不多了，如果很闲，那就设置为几个 M。

root@d4cad7fb69c2:/data# redis-cli info stats | grep sync
sync_full:0
sync_partial_ok:0
sync_partial_err:0  # 半同步失败次数

通过查看 sync_partial_err 变量的次数来决定是否需要扩大积压缓冲区，它表示主从半同步复制失败的次数。