Redis详解（7）性能监控：问题分析和优化

超、凢脫俗 2022-01-23 14:06 744阅读 0赞

对于任何应用服务和组件，都需要一套完善可靠谱监控方案。

尤其redis这类敏感的纯内存、高并发和低延时的服务，一套完善的监控告警方案，是精细化运营的前提。

## 一、Redis监控告警的价值 ##

--------------------

redis故障快速通知，定位故障点；对于DBA，redis的可用性和性能故障需快速发现和定位解决。  
分析redis故障的Root cause  
redis容量规划和性能管理  
redis硬件资源利用率和成本

### 1、redis故障快速发现，定位故障点和解决故障 ###

当redis出现故障时，DBA应在尽可能短时间内发现告警；如果故障对服务是有损的(如大面积网络故障或程序BUG)，需立即通知SRE和RD启用故障预案(如切换机房或启用emergency switch）止损。

如果没完善监控告警;假设由RD发现服务故障，再排查整体服务调用链去定位；甚于用户发现用问题，通过客服投诉，再排查到redis故障的问题；整个redis故障的发现、定位和解决时间被拉长，把一个原本的小故障被”无限”放大。

### 2、分析redis故障的根本原因 ###

任何一个故障和性能问题，其根本“诱因”往往只有一个，称为这个故障的Root cause。

一个故障从DBA发现、止损、分析定位、解决和以后规避措施；最重要一环就是DBA通过各种问题表象，层层分析到Root cause；找到问题的根据原因，才能根治这类问题，避免再次发生。

完善的redis监控数据，是我们分析root cause的基础和证据。

备注：Troubleshtooing定位Root cause，就像医生通过病人的病历和检查报告找到“真正的病灶”，让病人康复和少受苦，一样有意思和复杂；或像刑警通过案件的证据分析和推理，寻找那个唯一的真相，一样惊心动魄。(快看DBA又在吹牛了），其实在大型商业系统中，一次故障轻松就达直接损失数十万（间接损失更大），那“抓住元凶”，避免它再次“作案”，同样是“破案”。

问题表现是综合情的，一般可能性较复杂，这里举2个例子：

*  服务调用Redis响应时间变大的性能总是；可能网络问题，redis慢查询，redis QPS增高达到性能瓶颈，redis fork阻塞和请求排队，redis使用swap, cpu达到饱和(单核idle过低),aof fsync阻塞，网络进出口资源饱和等等
 *  redis使用内存突然增长，快达到maxmemory; 可能其个大键写入，键个数增长，某类键平均长度突增，fork COW, 客户端输入/输出缓冲区,lua程序占用等等

Root cause是要直观的监控数据和证据，而非有技术支撑的推理分析。

*  redis响应抖动，分析定位root casue是bgsave时fork导致阻塞200ms的例子。而不是分析推理：redis进程rss达30gb,响应抖动时应该有同步，fork子进程时，页表拷贝时要阻塞父进程，估计页表大小xx，再根据内存copy连续1m数据要xx 纳秒，分析出可能fork阻塞导致的。（要的不是这种分析）
    
    说明：粮厂有个习惯，在分析root cause尽量能拿到直观证据。因为一旦引入推理步骤，每一步的推理结果都可能出现偏差，最终可能给出错误root cause. “元凶”又逃过一劫，它下次作案估计就会更大。所以建议任何小的故障或抖动，至少从个人或小组内部，深入分析找到root cause；这样个人或组织都会成长快； 形成良好的氛围。

### 3、Redis容量规划和性能管理 ###

通过分析redis资源使用和性能指标的监控历史趋势数据；对集群进行合理扩容(Scale-out)、缩容(Scale-back)；对性能瓶颈优化处理等。

Redis资源使用饱和度监控，设置合理阀值；

一些常用容量指标：redis内存使用比例，swap使用，cpu单核的饱和度等；当资源使用容量预警时，能及时扩容，避免因资源使用过载，导致故障。

另一方面，如果资源利用率持续过低，及时通知业务，并进行redis集群缩容处理，避免资源浪费。

进一步，容器化管理redis后，根据监控数据，系统能自动地弹性扩容和缩容。

Redis性能监控管理，及时发现性能瓶颈，进行优化或扩容，把问题扼杀在”萌芽期“，避免它”进化“成故障。

### 4、Redis硬件资源利用率和成本 ###

从老板角度来看，最关心的是成本和资源利用率是否达标。

如果资源不达标，就得推进资源优化整合；提高硬件利用率，减少资源浪费。砍预算，减成本。

资源利用率是否达标的数据，都是通过监控系统采集的数据。

这一小节，扯了这么多； 只是强调redis不是只有一个端口存活监控就可以了。

下面进入主题，怎么采集redsis监控数。

老板曾说：监控告警和数据备份，是对DBA和SRE最基础也是最高的要求；

当服务和存储达到产品规模后，可认为“无监控，不服务；无备份，不存储”。

## 二、Redis监控的内容 ##

--------------------

针对redis监控，可以分为几个层面：

1、服务器系统相关：服务器宕机，CPU,

2、redis应用进程。

3、redis性能指标

4、应用的响应时间：Redis慢查询监控

## 2.1、服务器系统监控 ##

1)、服务器存活监控：

2）CPU

*  平均负载 (Load Average): 综合负载指标(暂且归类cpu子系统)，当系统的子系统出现过度使用时，平均负载会升高。可说明redis的处理性能下降(平均响应时间变长、吞吐量降低)。
 *  CPU整体利用率或饱和度 (cpu.busy): redis在高并发或时间复杂度高的指令，cpu整体资源饱和，导致redis性能下降，请求堆积。
 *  **CPU单核饱和度** (cpu.core.idle/core=0): redis是单进程模式，常规情况只使用一个cpu core, 单某个实例出现cpu性能瓶颈，导致性能故障，但系统一般24线程的cpu饱和度却很低。所以监控cpu单核心利用率也同样重样。
 *  **CPU上下文切换数** (cpu.switches)：context swith过高xxxxxx

3）内存和swap

*  **系统内存余量大小** (mem.memfree)：redis是纯内存系统，系统内存必须保有足够余量，避免出现OOM，导致redis进程被杀，或使用swap导致redis性能骤降。
 *  **系统swap使用量大小** (mem.swapused)：redis的”热数据“只要进入swap,redis处理性能就会骤降； 不管swap分区的是否是SSD介质。OS对swap的使用材质还是disk store. 这也是作者早期redis实现VM,后来又放弃的原因。

说明：系统内存余量合理，给各种缓冲区，fork cow足够的内存空间。

另一个问题：我的系统使用Redis缓存集群，”不怕挂，就怕慢“，或redis集群高可用做得厉害；这样redis的服务器是否能关闭swap呢？

4）磁盘

*  **磁盘分区的使用率** （df.bytes.used.percent)：磁盘空间使用率监控告警，确保有足磁盘空间用AOF/RDB, 日志文件存储。不过 redis服务器一般很少出现磁盘容量问题
 *  磁盘IOPS的饱和度(disk.io.util)：如果有AOF持久化时，要注意这类情况。如果AOF持久化，每秒sync有堆积，可能导致写入stall的情况。 另外磁盘顺序吞吐量还是很重要，太低会导致复制同步RDB时，拉长同步RDB时间。（期待diskless replication）

5）网络

*  网络吞吐量饱和度(net.if.out.bytes/net.if.in.bytes)：如果服务器是千兆网卡（Speed: 1000Mb/s），单机多实例情况，有异常的大key容量导致网卡流量打滿。redis整体服务等量下降，苦于出现故障切换。
 *  **丢包率** ：Redis服务响应质量受影响

## 2.2、Redis应用进程监控 ##

1)、端口存活

2)、进程占用的cpu和内存

3)、网络连接数

## 2.3、redis性能指标 ##

可以通过info 命令获取相关性能指标。

info命令输出的数据可分为10个类别，分别是：

*  server
 *  clients
 *  memory
 *  persistence
 *  stats
 *  replication
 *  cpu
 *  commandstats
 *  cluster
 *  keyspace

我们主要关注信息：

### Redis 连接数监控:clients ###

*   connected\_clients 连接个数：客户端连接个数，如果连接数过高，影响redis吞吐量。常规建议不要超过5000.参考 [**官方benchmarks**][benchmarks]
 *  connected\_clients\_pct(连接数使用率): 连接数使用百分比，通过(connected\_clients/macclients)计算；如果达到1，redis开始拒绝新连接创建。
 *  rejected\_connections(拒绝的连接个数): redis连接个数达到maxclients限制，拒绝新连接的个数。
 *  total\_connections\_received(新创建连接个数 ): 如果新创建连接过多，过度地创建和销毁连接对性能有影响，说明短连接严重或连接池使用有问题，需调研代码的连接设置。
 *  blocked\_clients (list阻塞调用被阻塞的连接个数 ):BLPOP这类命令没使用过，如果监控数据大于0，还是建议排查原因。

### Redis内存监控和优化:memory ###

*  used\_memory : redis真实使用内存，不包含内存碎片；单实例的内存大小不建议过大，常规10~20GB以内。
 *  used\_memory\_pct(redis内存使用比例): 已分配内存的百分比，通过(used\_memory/maxmemory)计算；对于redis存储场景会比较关注，未设置淘汰策略(maxmemory\_policy)的，达到maxmemory限制不能写入数据。
 *  used\_memory\_rss (redis进程使用内存大小): 进程实际使用的物理内存大小，包含内存碎片；如果rss过大导致内部碎片大，内存资源浪费，和fork的耗时和cow内存都会增大。
 *  mem\_fragmentation\_ratio(redis内存碎片率 ): 表示(used\_memory\_rss/used\_memory)，碎片率过大，导致内存资源浪费；
    
    说明：
    
    1、如果内存使用很小时，mem\_fragmentation\_ratio可以远大于1的情况，这个告警值不好设置，需参考used\_memory大小。
    
    2、如果mem\_fragmentation\_ratio小于1，表示redis已使用swap分区

**1、因内存交换引起的性能问题**

如果Redis实例的内存使用率超过可用最大内存 (used\_memory > 可用最大内存)，那么操作系统开始进行内存与swap空间交换，把内存中旧的或不再使用的内容写入硬盘上（硬盘上的这块空间叫Swap分区），以便留出新的物理内存给新页或活动页(page)使用。

如果Redis进程上发生内存交换，那么Redis和依赖Redis上数据的应用会受到严重的性能影响。 通过查看used\_memory指标可知道Redis正在使用的内存情况，如果used\_memory>可用最大内存，那就说明Redis实例正在进行内存交换或者已经内存交换完毕。

**2、跟踪内存使用率**

若是在使用Redis期间没有开启rdb快照或aof持久化策略，那么缓存数据在Redis崩溃时就有丢失的危险。因为当Redis内存使用率超过可用内存的95%时，部分数据开始在内存与swap空间来回交换，这时就可能有丢失数据的危险。

当开启并触发快照功能时，Redis会fork一个子进程把当前内存中的数据完全复制一份写入到硬盘上。因此若是当前使用内存超过可用内存的45%时触发快照功能，那么此时进行的内存交换会变的非常危险(可能会丢失数据)。 倘若在这个时候实例上有大量频繁的更新操作，问题会变得更加严重。

通过减少Redis的内存占用率，来避免这样的问题，或者使用下面的技巧来避免内存交换发生：

*  尽可能的使用Hash数据结构。因为Redis在储存小于100个字段的Hash结构上，其存储效率是非常高的。
 *  设置key的过期时间。一个减少内存使用率的简单方法就是，每当存储对象时确保设置key的过期时间。
 *  回收key。 若是启用了Redis快照功能，应该设置“maxmemory”值为系统可使用内存的45%，因为快照时需要一倍的内存来复制整个数据集，也就是说如果当前已使用45%，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其他的开销。 如果没开启快照功能，maxmemory最高能设置为系统可用内存的95%。

当内存使用达到设置的最大阀值时，需要选择一种key的回收策略，可在Redis.conf配置文件中修改“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值禁止淘汰数据。

### Redis综合性能监控 ###

**redis键空间的状态监控：**

*  keys（键个数 ): redis实例包含的键个数。建议控制在1kw内；单实例键个数过大，可能导致过期键的回收不及时。
 *  keys\_expires（设置有生存时间的键个数 ): 是纯缓存或业务的过期长，都建议对键设置TTL; 避免业务的死键问题. （expires字段）
 *  avg\_ttl (估算设置生存时间键的平均寿命 ): redis会抽样估算实例中设置TTL键的平均时长，单位毫秒。如果无TTL键或在Slave则avg\_ttl一直为0
 *  evicted\_keys (LRU淘汰的键个数 ): 因used\_memory达到maxmemory限制，并设置有淘汰策略的实例；（对排查问题重要，可不设置告警）
 *  expired\_keys (**过期淘汰的键个数** ): 删除生存时间为0的键个数；包含主动删除和定期删除的个数。

**Redis qps：**

*  total\_commands\_processed (**redis处理的命令数** ): 监控采集周期内的平均qps,   
    redis单实例处理达数万，如果请求数过多，redis过载导致请求堆积。
 *  instantaneous\_ops\_per\_sec(**redis当前的qps** ): redis内部较实时的每秒执行的命令数；可和total\_commands\_processed监控互补。

在Redis实例中，跟踪命令处理总数是解决响应延迟问题最关键的部分，因为Redis是个单线程模型，客户端过来的命令是按照顺序执行的。比较常见的延迟是带宽，通过千兆网卡的延迟大约有200μs。倘若明显看到命令的响应时间变慢，延迟高于200μs，那可能是Redis命令队列里等待处理的命令数量比较多。 如上所述，延迟时间增加导致响应时间变慢可能是由于一个或多个慢命令引起的，这时可以看到每秒命令处理数在明显下降，甚至于后面的命令完全被阻塞，导致Redis性能降低。要分析解决这个性能问题，需要跟踪命令处理数的数量和延迟时间。

**Redis cmdstat\_xxx**

redis记录执行过的所有命令； 通过info all的Commandstats节采集数据.

*  cmdstat\_xxx (**每类命令执行的次数** ): 这个值用于分析redis抖动变化比较有用

以下表示：每个命令执行次数，总共消耗的CPU时长(单个微秒)，平均每次消耗的CPU时长（单位微秒）

# Commandstats
    cmdstat_set:calls=6,usec=37,usec_per_call=6.17
    cmdstat_lpush:calls=4,usec=32,usec_per_call=8.00
    cmdstat_lpop:calls=4,usec=33,usec_per_call=8.25

**Redis Keysapce hit ratio**

redis键空间请求命中率监控，通过此监控来度量redis缓存的质量，如果未命中率或次数较高，可能因热点数据已大于redis的内存限制，导致请求落到后端存储组件，可能需要扩容redis缓存集群的内存容量。当然也有可能是业务特性导致。

*  keyspace\_hits(请求键被命中次数 ): redis请求键被命中的次数
 *  keyspace\_misses (请求键未被命中次数 ): redis请求键未被命中的次数；当命中率较高如95%，如果请求量大，未命中次数也会很多。可参考Baron大神写的 [**Why you should ignore MySQL’s key cache hit ratio**][Why you should ignore MySQL_s key cache hit ratio]
 *  keyspace\_hit\_ratio**(请求键的命中率** ):使用keyspace\_hits/(keyspace\_hits+keyspace\_misses)计算所得，是度量Redis缓存服务质量的标准

**Redis fork**

redis在执行BGSAVE,BGREWRITEAOF命令时，redis进程有 [fork ][fork]操作。而fork会对redis进程有个短暂的卡顿,这个卡顿redis不能响应任务请求。所以监控fork阻塞时长，是相当重要。

如果你的系统不能接受redis有500ms的阻塞，那么就要监控fork阻塞时长的变化，做好容量规划。

*  latest\_fork\_usec (**最近一次fork阻塞的微秒数** ): 最近一次Fork操作阻塞redis进程的耗时数，单位微秒。

**redis network traffic**

redis一般单机多实例部署，当服务器网络流量增长很大，需快速定位是网络流量被哪个redis实例所消耗了； 另外redis如果写流量过大，可能导致slave线程“客户端输出缓冲区”堆积，达到限制后被Maser强制断开连接，出现复制中断故障。所以我们需监控每个redis实例网络进出口流量，设置合适的告警值。

说明：网络监控指标 ，需较高的版本才有，应该是2.8.2x以后

*  total\_net\_input\_bytes:**redis网络入口流量字节数**
 *  total\_net\_output\_bytes:**redis网络出口流量字节数**
 *  instantaneous\_input\_kbps:**redis网络入口kps** 
 *  instantaneous\_output\_kbps:**redis网络出口kps**

前两者是累计值，根据监控平台1个采集周期(如1分钟)内平均每秒的流量字节数。

### **Redis持久化监控** ###

redis存储场景的集群，就得 [redis持久化 ][redis]保障数据落地，减少故障时数据丢失。这里分析redis rdb数据持久化的几个监控指标。

*  rdb\_last\_bgsave\_status **最近一次rdb持久化是否成功**:如果持久化未成功，建议告警，说明备份或主从复制同步不正常。或redis设置有”stop-writes-on-bgsave-error”为yes，当save失败后，会导致redis不能写入操作
 *  rdb\_last\_bgsave\_time\_sec**最近一次成功生成rdb文件耗时秒数** ):rdb生成耗时反应同步时数据是否增长； 如果远程备份使用redis-cli –rdb方式远程备份rdb文件，时间长短可能影响备份线程客户端输出缓冲内存使用大小。
 *  rdb\_changes\_since\_last\_save**离最近一次成功生成rdb文件，写入命令的个数**):即有多少个写入命令没有持久化，最坏情况下会丢失的写入命令数。建议设置监控告警
 *  rdb\_last\_save\_time**离最近一次成功rdb持久化的秒数**: 最坏情况丢失多少秒的数据写入。使用当前时间戳 - 采集的rdb\_last\_save\_time(最近一次rdb成功持久化的时间戳)，计算出多少秒未成功生成rdb文件

### Redis复制监控 ###

不论使用何种redis集群方案， [*redis复制 *][redis 1]都会被使用。

复制相关的监控告警项：

*  redis\_role **redis角色** ):实例的角色，是master or slave
 *  master\_link\_status**复制连接状态** : slave端可查看它与master之间同步状态；当复制断开后表示down,影响当前集群的可用性。需设置监控告警。
 *  master\_link\_down\_since\_seconds**复制连接断开时间长度** ):主从服务器同步断开的秒数，建议设置时长告警。
 *  master\_last\_io\_seconds**主库多少秒未发送数据到从库** ):如果主库超过repl-timeout秒未向从库发送命令和数据，会导致复制断开重连。详细分析见文章： [Redis复制中断和无限同步问题][Redis] 。 在slave端可监控，建议设置大于10秒告警
 *  slave\_lag**从库多少秒未向主库发送REPLCONF命令** : 正常情况从库每秒都向主库，发送REPLCONF ACK命令；如果从库因某种原因，未向主库上报命令，主从复制有中断的风险。通过在master端监控每个slave的lag值。
 *  slave\_read\_only**从库是否设置只读** )：从库默认只读禁止写入操作，监控从库只读状态；   
    如果关闭从库只读，有写入数据风险。关于主从数据不一致,见文章分析： [Redis复制主从数据不-致][Redis_-]
 *  connected\_slaves**主库挂载的从库个数** ):主库至少保证一个从库，不建议设置超过2个从库。
 *  repl\_backlog\_active:**复制积压缓冲区是否开启** :主库默认开启复制积压缓冲区，用于应对短时间复制中断时，使用 **部分同步** 方式。
 *  repl\_backlog\_size**复制积压缓冲大小** :主库复制积压缓冲大小默认1MB,因为是redis server共享一个缓冲区，建议设置100MB.
    
    说明： 关于根据实际情况，设置合适大小的复制缓冲区。可以通过master\_repl\_offset指标计算每秒写入字节数，同时乘以希望多少秒内闪断使用“部分同步”方式。

### Redis集群监控 ###

这里所写 [redis官方集群方案][redis 2] 的监控指标

数据基本通过cluster info和info命令采集。

*  cluster\_enabled**实例是否启用集群模式** ): 通过info的cluster\_enabled监控是否启用集群模式。
 *  clusster\_state**集群健康状态** :如果当前redis发现有failed的slots，默认为把自己cluster\_state从ok个性为fail, 写入命令会失败。如果设置cluster-require-full-coverage为NO,则无此限制。
 *  cluster\_slots\_assigned**集群数据槽slots分配情况** :集群正常运行时，默认16384个slots
 *  cluster\_slots\_fail**检测下线的数据槽slots个数** :集群正常运行时，应该为0. 如果大于0说明集群有slot存在故障。
 *  cluster\_size**集群的分片数** ）：集群中设置的分片个数
 *  cluster\_known\_nodes**集群的节点数** ）：集群中redis节点的个数

## 2.4、Redis响应时间监控 ##

[*响应时间 *][Link 1]是衡量一个服务组件性能和质量的重要指标。使用redis的服务通常对响应时间都十分敏感，比如要求99%的响应时间达10ms以内。

因redis的慢查询日志只计算命令的cpu占用时间，不会考虑排队或其他耗时。

*  respond\_time\_max**最长响应时间** ):最长响应时间的毫秒数
 *  respond\_time\_99\_max **：99%的响应时间长度** ):
 *  respond\_time\_99\_avg：**99%的平均响应时间长度** ():
 *  respond\_time\_95\_max **95%的响应时间长度** （):
 *  respond\_time\_95\_avg **95%的平均响应时间长度** ():

响应时间监控的方式建议，最简单方法，使用 [*Percona tcprstat*][Percona tcprstat]

**Redis慢查询监控**

[redis慢查询 ][redis 3]是排查性能问题关键监控指标。因redis是单线程模型(single-threaded server),即一次只能执行一个命令，如果命令耗时较长，其他命令就会被阻塞，进入队列排队等待；这样对程序性能会较大。

redis慢查询保存在内存中，最多保存slowlog-max-len(默认128）个慢查询命令，当慢查询命令日志达到128个时，新慢查询被加入前，会删除最旧的慢查询命令。因慢查询不能持久化保存，且不能实时监控每秒产生的慢查询个数。

我们建议的慢查询监控方法：

1.  slowlog-log-slower-than 设置合理慢查询日志阀值,, 建议1ms(如果平均1ms, redis qps也就只有1000)
2.  slowlog-max-len 设置全理慢查询日志队列长度，建议大于1024个，因监控采集周期1分钟，建议，避免慢查询日志被删除；另外慢查询的参数过多时，会被省略，对内存消耗很小
3.  slowlog len 每次采集使用获取慢查询日志个数
4.  slowlog get 1024  每次彩集使用获取所慢查询，并转存储到其他地方，如MongoDB或MySQL等，方便排查问题；并分析当前慢查询日志最长耗时微秒数。
5.  slowlog reset 然后使用把慢查询日志清空，下个采集周期的日志长度就是最新产生的。

redis慢查询的监控项：

*  **redis慢查询日志个数** （slowlog\_len):每个采集周期出现慢查询个数，如1分钟出现10次大于1ms的慢查询
 *  **redis慢查询日志最长耗时值** (slowlog\_max\_time)：获取慢查询耗时最长值，因有的达10秒以下的慢查询，可能导致复制中断，甚至出来主从切换等故障。

Redis中的slowlog命令可以让我们快速定位到那些超出指定执行时间的慢命令，默认情况下命令若是执行时间超过10ms就会被记录到日志。slowlog只会记录其命令执行的时间，不包含io往返操作，也不记录单由网络延迟引起的响应慢。通常1gb带宽的网络延迟，预期在200μs左右，倘若一个命令仅执行时间就超过10ms，那比网络延迟慢了近50倍。 想要查看所有执行时间比较慢的命令，可以通过使用Redis-cli工具，使用slowlog get命令查看，返回结果的第三个字段以微妙位单位显示命令的执行时间。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70][]

图中字段分别意思是：

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

# *三、Redis info详细详解* #

--------------------

\# Server  
redis\_version:3.2.3 \#redis版本号  
redis\_git\_sha1:00000000 \#git sha1摘要值  
redis\_git\_dirty:0  \#git dirty标识  
redis\_build\_id:443e50c39cbcdbe0 \#redis构建id  
redis\_mode:standalone  \#运行模式：standalone、sentinel、cluster  
os:Linux 3.10.0-514.16.1.el7.x86\_64 x86\_64 \#服务器宿主机操作系统  
arch\_bits:64 服务器宿主机CUP架构（32位/64位）  
multiplexing\_api:epoll \#redis IO机制  
gcc\_version:4.8.5  \#编译 redis 时所使用的 GCC 版本  
process\_id:1508  \#服务器进程的 PID  
run\_id:b4ac0f9086659ce54d87e41d4d2f947e19c28401 \#redis 服务器的随机标识符 （用于 Sentinel 和集群）  
tcp\_port:6380  \#redis服务监听端口  
uptime\_in\_seconds:520162 \#redis服务启动以来经过的秒数  
uptime\_in\_days:6 \#redis服务启动以来经过的天数  
hz:10  \#redis内部调度（进行关闭timeout的客户端，删除过期key等等）频率，程序规定serverCron每秒运行10次  
lru\_clock:16109450 \#自增的时钟，用于LRU管理,该时钟100ms(hz=10,因此每1000ms/10=100ms执行一次定时任务)更新一次  
executable:/usr/local/bin/redis-server  
config\_file:/data/redis-6380/redis.conf 配置文件的路径

\# Clients  
connected\_clients:2   \#已连接客户端的数量（不包括通过从属服务器连接的客户端）  
client\_longest\_output\_list:0 \#当前连接的客户端当中，最长的输出列表  
client\_biggest\_input\_buf:0 \#当前连接的客户端当中，最大输入缓存  
blocked\_clients:0 \#正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量

\# Memory  
used\_memory:426679232 \#由 redis 分配器分配的内存总量，以字节（byte）为单位  
used\_memory\_human:406.91M   \#以可读的格式返回 redis 分配的内存总量（实际是used\_memory的格式化）  
used\_memory\_rss:443179008 \#从操作系统的角度，返回 redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps等命令的输出一致  
used\_memory\_rss\_human:422.65M \# redis 的内存消耗峰值(以字节为单位)   
used\_memory\_peak:426708912  
used\_memory\_peak\_human:406.94M  
total\_system\_memory:16658403328  
total\_system\_memory\_human:15.51G  
used\_memory\_lua:37888   \# Lua脚本存储占用的内存  
used\_memory\_lua\_human:37.00K  
maxmemory:0  
maxmemory\_human:0B  
maxmemory\_policy:noeviction  
mem\_fragmentation\_ratio:1.04 \# used\_memory\_rss/ used\_memory  
mem\_allocator:jemalloc-4.0.3

\# Persistence  
loading:0 \#服务器是否正在载入持久化文件，0表示没有，1表示正在加载  
rdb\_changes\_since\_last\_save:3164272  \#离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化  
rdb\_bgsave\_in\_progress:0 \#服务器是否正在创建rdb文件，0表示否  
rdb\_last\_save\_time:1559093160  \#离最近一次成功创建rdb文件的时间戳。当前时间戳 - rdb\_last\_save\_time=多少秒未成功生成rdb文件  
rdb\_last\_bgsave\_status:ok  \#最近一次rdb持久化是否成功  
rdb\_last\_bgsave\_time\_sec:-1  \#最近一次成功生成rdb文件耗时秒数  
rdb\_current\_bgsave\_time\_sec:-1 \#如果服务器正在创建rdb文件，那么这个域记录的就是当前的创建操作已经耗费的秒数  
aof\_enabled:0 \#是否开启了aof  
aof\_rewrite\_in\_progress:0 \#标识aof的rewrite操作是否在进行中  
aof\_rewrite\_scheduled:0  \#rewrite任务计划，当客户端发送bgrewriteaof指令，如果当前rewrite子进程正在执行，那么将客户端请求的bgrewriteaof变为计划任务，待aof子进程结束后执行rewrite  
aof\_last\_rewrite\_time\_sec:-1 \#最近一次aof rewrite耗费的时长  
aof\_current\_rewrite\_time\_sec:-1 \#如果rewrite操作正在进行，则记录所使用的时间，单位秒  
aof\_last\_bgrewrite\_status:ok \#上次bgrewriteaof操作的状态  
aof\_last\_write\_status:ok \#上次aof写入状态

\# Stats  
total\_connections\_received:10   \#服务器已经接受的连接请求数量  
total\_commands\_processed:9510792   \#redis处理的命令数  
instantaneous\_ops\_per\_sec:1   \#redis当前的qps，redis内部较实时的每秒执行的命令数  
total\_net\_input\_bytes:1104411373   \#redis网络入口流量字节数  
total\_net\_output\_bytes:66358938 \#redis网络出口流量字节数  
instantaneous\_input\_kbps:0.04  \#redis网络入口kps  
instantaneous\_output\_kbps:3633.35  \#redis网络出口kps  
rejected\_connections:0  \#拒绝的连接个数，redis连接个数达到maxclients限制，拒绝新连接的个数  
sync\_full:0  \#主从完全同步成功次数  
sync\_partial\_ok:0  \#主从部分同步成功次数  
sync\_partial\_err:0  \#主从部分同步失败次数  
expired\_keys:0   \#运行以来过期的key的数量  
evicted\_keys:0  \#运行以来剔除(超过了maxmemory后)的key的数量  
keyspace\_hits:87  \#命中次数  
keyspace\_misses:17   \#没命中次数  
pubsub\_channels:0  \#当前使用中的频道数量  
pubsub\_patterns:0  \#当前使用的模式的数量  
latest\_fork\_usec:0   \#最近一次fork操作阻塞redis进程的耗时数，单位微秒  
migrate\_cached\_sockets:0   \#是否已经缓存了到该地址的连接

\# Replication  
role:master  \#实例的角色，是master or slave  
connected\_slaves:0  \#连接的slave实例个数  
master\_repl\_offset:0 \#主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟，与master\_replid可被用来标识主实例复制流中的位置  
repl\_backlog\_active:0   \#复制积压缓冲区是否开启  
repl\_backlog\_size:1048576  \#复制积压缓冲大小  
repl\_backlog\_first\_byte\_offset:0  \#复制缓冲区里偏移量的大小  
repl\_backlog\_histlen:0   \#此值等于 master\_repl\_offset - repl\_backlog\_first\_byte\_offset,该值不会超过repl\_backlog\_size的大小

\# CPU  
used\_cpu\_sys:507.00  \#将所有redis主进程在核心态所占用的CPU时求和累计起来  
used\_cpu\_user:280.48   \#将所有redis主进程在用户态所占用的CPU时求和累计起来  
used\_cpu\_sys\_children:0.00  \#将后台进程在核心态所占用的CPU时求和累计起来  
used\_cpu\_user\_children:0.00  将后台进程在用户态所占用的CPU时求和累计起来

\# Cluster  
cluster\_enabled:0

\# Keyspace  
db0:keys=5557407,expires=362,avg\_ttl=604780497  
db15:keys=1,expires=0,avg\_ttl=0

[benchmarks]: http://redis.io/topics/benchmarks
[Why you should ignore MySQL_s key cache hit ratio]: https://www.percona.com/blog/2010/02/28/why-you-should-ignore-mysqls-key-cache-hit-ratio/
[fork]: http://man7.org/linux/man-pages/man2/fork.2.html
[redis]: http://redis.io/topics/persistence
[redis 1]: http://redis.io/topics/replication
[Redis]: https://zhuoroger.github.io/2016/07/31/redis-replication-broken-and-loopsync/
[Redis_-]: https://zhuoroger.github.io/2016/08/13/redis-replication-inconsistence/
[redis 2]: http://redis.io/topics/cluster-spec
[Link 1]: https://en.wikipedia.org/wiki/Response_time_%28technology
[Percona tcprstat]: https://www.percona.com/docs/wiki/tcprstat_start.html
[redis 3]: http://redis.io/commands/slowlog
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2hndWlzdQ_size_16_color_FFFFFF_t_70]: /images/20220123/68dc773bd1b14532abc9cfbc208077de.png