redis info 详解

查看Redis的性能状态不得不提到info。

官方文档http://redis.io/commands/info

下面简单的介绍一下info的信息：
info主要有一下几项，因版本不同可能略有差别

• server
• clients
• memory
• persistence
• stats
• replication
• cpu
• keyspace

server段一般是配置以及系统项不用特别的关注。

client段：

# Clients
connected_clients:2053  #当前客户端连接数
client_longest_output_list:0    #当前连接的客户端当中，最长的输出列表
client_biggest_input_buf:0      # 当前连接的客户端当中，最大输入缓存
blocked_clients:0               #被阻塞的客户端数

因为Redis是单线程模型(只能使用单核)，来处理所有客户端的请求， 但由于客户端连接数的增长，处理请求的线程资源开始降低分配给单个客户端连接的处理时间，这时每个客户端需要花费更多的时间去等待Redis共享服务的响应。

因为Redis是单线程模型(只能使用单核)，来处理所有客户端的请求，且Redis默认允许客户端连接的最大数量是10000。若是看到连接数超过5000以上，那可能会影响Redis的性能。因此监控客户端连接数是非常重要的，因为客户端创建连接数的数量可能超出预期的数量，也可能是客户端端没有有效的释放连接。

相关配置项：

maxclients 10000
tcp-backlog 10240  #TCP 监听的最大容纳数量 默认511

memory段：

# Memory    
used_memory:65256464            #使用内存，以字节（byte）为单位
used_memory_human:62.23M        #以人类可读的格式返回 Redis 分配的内存总量
used_memory_rss:54554624        #系统给redis分配的内存即常驻内存，和top 、 ps 等命令的输出一致。
used_memory_peak:2857386920     #内存使用的峰值大小
used_memory_peak_human:2.66G    #以人类可读的格式返回 Redis 的内存峰值
used_memory_lua:33792           #lua引擎使用的内存
mem_fragmentation_ratio:0.84    #redis 内存碎片率
mem_allocator:jemalloc-3.6.0    #内存分配器

在使用redis经常会因为memory引发一些列的问题。像因为内存交换产生的性能问题以及延迟问题等。

我们可以通过一下几种方式来减少redis内存交换的发生

1. 使用Hash Redis在储存小于100个字段的Hash结构上，其存储效率是非常高的。官方也建议我们尽可能多的使用Hash存储。Hash的操作命令是HSET(key, fields, value)和HGET。
2. 设置key的过期时间
3. 回收key 设置要maxmemory，切redis实例启用了rdb功能就需要将maxmemory设置为系统可使用内存的45%，因为快照时需要一倍的内存来复制整个数据集，也就是说如果当前已使用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其他的开销。如果没开启快照功能，maxmemory最高能设置为系统可用内存的95%。
   当内存使用达到设置的最大阀值时，需要选择一种key的回收策略，即配置文件中的maxmemory-policy字段设置
   若是Redis数据集中的key都设置了过期时间，那么volatile-ttl策略是比较好的选择。但如果key在达到最大内存限制时没能够迅速过期，或者根本没有设置过期时间。那么设置为allkeys-lru值比较合适，它允许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。

Redis还提供了一些其他淘汰策略，如下：

• volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据。
• volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰。
• volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰。
• allkeys-lru：使用LRU算法从所有数据集合中淘汰数据。
• allkeys-random：从数据集合中任意选择数据淘汰。
• no-enviction：禁止淘汰数据。

通过设置maxmemory为系统可用内存的45%或95%(取决于持久化策略)和设置maxmemory-policy为volatile-ttl或allkeys-lru(取决于过期设置)，可以比较准确的限制Redis最大内存使用率，在绝大多数场景下使用这2种方式可确保Redis不会进行内存交换。倘若你担心由于限制了内存使用率导致丢失数据的话，可以设置noneviction值禁止淘汰数据。

另外一定要配置/proc/sys/vm/min_free_kbytes 让系统及时回收内存
echo 102400 >　/proc/sys/vm/min_free_kbytes 设置100m开始回收内存

persistence 段

# Persistence
loading:0
rdb_changes_since_last_save:1866    #自上次dump后rdb的改动
rdb_bgsave_in_progress:0            #标识rdb save是否进行中
rdb_last_save_time:1452048771       #上次save的时间戳
rdb_last_bgsave_status:ok           #上次的save操作状态
rdb_last_bgsave_time_sec:0          #上次rdb save操作使用的时间(单位s)
rdb_current_bgsave_time_sec:-1      #如果rdb save操作正在进行，则是所使用的时间
aof_enabled:1                       #是否开启aof，默认没开启(已开启)
aof_rewrite_in_progress:0           #标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0             #标识是否将要在rdb save操作结束后执行
aof_last_rewrite_time_sec:0         #上次rewrite操作使用的时间(单位s)
aof_current_rewrite_time_sec:-1     #如果rewrite操作正在进行，则记录所使用的时间
aof_last_bgrewrite_status:ok        #上次rewrite操作的状态
aof_last_write_status:ok            #上次write操作的状态
aof_current_size:42820373           #aof当前大小，以字节（byte）为单位
aof_base_size:16223723              #aof上次启动或rewrite的大小
aof_pending_rewrite:0               #同上面的aof_rewrite_scheduled
aof_buffer_length:0                 #aof buffer的大小
aof_rewrite_buffer_length:0         #aof rewrite buffer的大小
aof_pending_bio_fsync:0             #后台IO队列中等待fsync任务的个数
aof_delayed_fsync:41394             #延迟的fsync计数器 TODO

stats段

# Stats
total_connections_received:61264941 #自启动起连接过的总数
total_commands_processed:951647408  #自启动起运行命令的总数
instantaneous_ops_per_sec:13        #每秒执行的命令个数
rejected_connections:0              #因为最大客户端连接书限制，而导致被拒绝连接的个数
sync_full:23                        
sync_partial_ok:0                   
sync_partial_err:0
expired_keys:40225836               #自启动起过期的key的总数
evicted_keys:0                      #因为内存大小限制，而被驱逐出去的键的个数
keyspace_hits:54841673              #自启动起命中key的个数
keyspace_misses:344507              #自启动起未命中key的个数
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:8775               #上次的fork操作使用的时间（单位ms）

因为Redis是个单线程模型，客户端过来的命令是按照顺序执行的。因此网络问题、慢命令会造成阻塞导致redis性能下降。

如果发生命令阻塞就可以看到每秒命令处理数在明显下降。要分析解决这个性能问题，需要跟踪命令处理数的数量和延迟时间。

降低延迟的几个技巧：

1. 使用多参数命令 若是客户端在很短的时间内发送大量的命令过来，会发现响应时间明显变慢，这由于后面命令一直在等待队列中前面大量命令执行完毕。因此我们可以使用单命令多参数的方式，来减少操作。例如mset mget hmset hmget等。
2. 管道拼接，降低网络延迟
3. 避免操作大集合的慢命令

产看redis延迟时间

[root@13 ~]# /usr/local/redis6379/bin/redis-cli -c -h 192.168.11.13 -p 6380 --latency 
min: 0, max: 3, avg: 0.16 (9746 samples)

本机的延迟是160μs

查询慢日志：

redis-cli   -h 127.0.0.1 -p 6379 slowlog get
 1) 1) (integer) 11
    2) (integer) 1451987715
    3) (integer) 14387
    4) 1) "CONFIG"
       2) "GET"
       3) "*

1)日志的唯一标识符
2)被记录命令的执行时间点，以 UNIX 时间戳格式表示
3)查询执行时间，以微秒为单位。例子中命令使用14毫秒。
4)执行的命令，以数组的形式排列。完整命令是config get *

replication段

# Replication
role:master                                     #角色（主从）
connected_slaves:1                              #从库数量
slave0:ip=10.15.x.x,port=6379,state=online,offset=2230297606,lag=2 #从库信息
master_repl_offset:2230300129   
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2229251554
repl_backlog_histlen:1048576

cpu段

# CPU
used_cpu_sys:23111.87                   #cpu在内核态所消耗的cpu的时间
used_cpu_user:17763.81                  #cpu在用户态所消耗的cpu的时间
used_cpu_sys_children:7909.22
used_cpu_user_children:62767.11

key段

# Keyspace
db0:keys=85904,expires=81390,avg_ttl=47463342

​