Redis常用监控和优化方案

1.图形化监控

RedisLive:

  1. 安装Python,要求版本2.7以上。
  2. 安装依赖组件:pip install tornado;pip install python-dateutil
  3. 安装Redis-Live:下载源码,编辑redis-live.conf文件增加要监控的redis server host;Redis常用监控和优化方案_第1张图片
  4. 开启监控脚本:./redis-monitor.py –duration 120 & 开启webserver:./redis-live.py &
  5. 在浏览器中输入如下地址来查看RedisLive:http://localhost:8888/index.html

2.命令行监控

  1. INFO命令详解
    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 的部分内存被操作系统换出到交换空间了,在这种情况下,操作可能会产生明显的延迟。
    Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
    当 Redis 释放内存时,分配器可能会,也可能不会,将内存返还给操作系统。
    如果 Redis 释放了内存,却没有将内存返还给操作系统,那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。

  2. 用内存碎片率预测性能问题
    A.重启Redis服务器:如果内存碎片率超过1.5,重启Redis服务器可以让额外产生的内存碎片失效并重新作为新内存来使用,使操作系统恢复高效的内存管理。额外碎片的产生是由于Redis释放了内存块,但内存分配器并没有返回内存给操作系统,这个内存分配器是在编译时指定的,可以是libc、jemalloc或者tcmalloc。 通过比较used_memory_peak, used_memory_rss和used_memory_metrics的数据指标值可以检查额外内存碎片的占用。从名字上可以看出,used_memory_peak是过去Redis内存使用的峰值,而不是当前使用内存的值。如果used_memory_peak和used_memory_rss的值大致上相等,而且二者明显超过了used_memory值,这说明额外的内存碎片正在产生。 在Redis-cli工具上输入info memory可以查看上面三个指标的信息。在重启服务器之前,需要在Redis-cli工具上输入shutdown save命令,意思是强制让Redis数据库执行保存操作并关闭Redis服务,这样做能保证在执行Redis关闭时不丢失任何数据。 在重启后,Redis会从硬盘上加载持久化的文件,以确保数据集持续可用。

  3. 延迟时间
    Redis的延迟数据是无法从info信息中获取的。倘若想要查看延迟时间,可以用 Redis-cli工具加–latency参数运行,如:
    Redis-cli --latency -h 127.0.0.1 -p 6379

  4. 使用slowlog查出引发延迟的慢命令

  5. 监控客户端的连接,Redis-cli工具中输入info clients可以查看到当前实例的所有客户端连接信息。Redis默认允许客户端连接的最大数量是10000。若是看到连接数超过5000以上,那可能会影响Redis的性能。

  6. 回收key
    A. info信息中的evicted_keys字段显示的是,因为maxmemory限制导致key被回收删除的数量。回收key的情况只会发生在设置maxmemory值后,不设置会发生内存交换。可以在配置文件中设置maxmemory-policy值为“volatile-lru”或“volatile-ttl”,来确定Redis是使用lru策略还是过期时间策略。 倘若所有的key都有明确的过期时间,那过期时间回收策略是比较合适的。若是没有设置key的过期时间或者说没有足够的过期key,那设置lru策略是比较合理的,这可以回收key而不用考虑其过期状态。
    B.根据key回收定位性能问题
    跟踪key回收是非常重要的,因为通过回收key,可以保证合理分配Redis有限的内存资源。如果evicted_keys值经常超过0,那应该会看到客户端命令响应延迟时间增加,因为Redis不但要处理客户端过来的命令请求,还要频繁的回收满足条件的key。需要注意的是,回收key对性能的影响远没有内存交换严重,若是在强制内存交换和设置回收策略做一个选择的话,选择设置回收策略是比较合理的,因为把内存数据交换到硬盘上对性能影响非常大。

  7. 减少回收key以提升性能
    减少回收key的数量是提升Redis性能的直接办法,下面有2种方法可以减少回收key的数量:
    (1)增加内存限制:倘若开启快照功能,maxmemory需要设置成物理内存的45%,这几乎不会有引发内存交换的危险。若是没有开启快照功能,设置系统可用内存的95%是比较合理的,具体参考前面的快照和maxmemory限制章节。如果maxmemory的设置是低于45%或95%(视持久化策略),通过增加maxmemory的值能让Redis在内存中存储更多的key,这能显著减少回收key的数量。 若是maxmemory已经设置为推荐的阀值后,增加maxmemory限制不但无法提升性能,反而会引发内存交换,导致延迟增加、性能降低。 maxmemory的值可以在Redis-cli工具上输入config set maxmemory命令来设置。
    需要注意的是,这个设置是立即生效的,但重启后丢失,需要永久化保存的话,再输入config rewrite命令会把内存中的新配置刷新到配置文件中。
    (2)对实例进行分片:分片是把数据分割成合适大小,分别存放在不同的Redis实例上,每一个实例都包含整个数据集的一部分。通过分片可以把很多服务器联合起来存储数据,相当于增加总的物理内存,使其在没有内存交换和回收key的策略下也能存储更多的key。假如有一个非常大的数据集,maxmemory已经设置,实际内存使用也已经超过了推荐设置的阀值,那通过数据分片能明显减少key的回收,从而提高Redis的性能。 分片的实现有很多种方法,下面是Redis实现分片的几种常见方式:
    a. Hash分片:一个比较简单的方法实现,通过Hash函数计算出key的Hash值,然后值所在范围对应特定的Redis实例。
    b. 代理分片:客户端把请求发送到代理上,代理通过分片配置表选择对应的Redis实例。 如Twitter的Twemproxy,豌豆荚的codis。
    c. 一致性Hash分片
    d. 虚拟桶分片

你可能感兴趣的:(Redis常用监控和优化方案)