Redis性能监控及优化-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

Redis性能监控及优化

简介: Redis 监控 参数 优化

  Redis是一个纯内存的Key-Value型数据库,可以提供高并发和低延时的服务,生产上Redis的性能将会直接影响到服务的质量。对此本文将主要对Redis的性能指标、监控工具以及性能优化方法进行介绍。

一、Redis性能指标

1.1 Redis性能压力

  Redis性能压力主要源于响应时间变慢和内存突然增长,甚至达到上限的问题。其原因主要有以下几个方面:

  • 慢查询
  • 大对象和大键/键个数增长、平均长度突增
  • 网络通信延迟
  • Redis持久化引发的延迟
  • 数据淘汰引发的延迟

  当Redis出现问题时,我们很难直接定位到具体原因,需要通过Redis的监控提供的信息进行分析才能得到答案。

1.2 Redis监控参数

  Redis可以通过info all命令的的输出获取相关性能指标。可以分为以下十类:

  • server(基本信息)
  • clients(连接信息)
  • memory(内存信息)
  • persistence(持久化信息)
  • stats(命令等状态信息)
  • replication(复制信息)
  • cpu(CPU相关信息)
  • cluster(集群信息)
  • keyspace(键空间信息)
  • commandstats(调用命令相关信息)

  在下面的介绍中,我将会介绍各类信息中的关键参数,其余部分可以自行研究。

1.2.1 Server

uptime_in_days:从Redis server 启动到现在的天数

1.2.2 Clients

connected_clients:已连接客户端的数量 (不包括从服务器)
blocked_clients:正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量

1.2.3 Memory

used_memory:已使用的内存(不包含内存碎片)
used_memory_rss:已使用的内存(包含内存碎片)
used_memory_peak:过去Redis内存使用的峰值
maxmemory:最大内存
通过used_memory/maxmemory可以计算出内存使用率,未设置淘汰策略(maxmemory_policy)时,达到maxmemory限制不能写入数据。

1.2.4 Persistence

rdb_last_bgsave_status/aof_last_write_statu/aof_last_bgrewrite_statuss:最后一次持久化/AOF重写状态
aof_pending_bio_fsync:后台IO队列中等待fsync的任务数
aof_current_size:AOF当前文件大小

1.2.5 Stats

total_commands_processed:服务器已执行的命令数量
instantaneous_ops_per_sec:每秒执行命令数
rejected_connections:因为最大客户端数量限制而被拒绝的连接请求数量
expired_keys:过期的数据库键数量
evicted_keys:因最大内存容量限制而被驱逐的键数量
keyspace_hits:键空间命中数
keyspace_misses:键空间未命中数
total_net_input_bytes:网络流入总流量
total_net_output_bytes:网络流出总流量

1.2.6 Replication

master_link_status:主从连接状态
master_repl_offset:主从间这个变量的差距代表延迟的偏移量

1.2.7 CPU

used_cpu_sys:Redis服务器耗费的系统CPU
used_cpu_user:Redis服务器耗费的用户CPU
used_cpu_sys_children:Redis后台进程耗费的系统CPU
used_cpu_user_children:Redis后台进程耗费的用户CPU

1.2.8 Cluster

cluster_enabled:是否使用集群

1.2.9 Keyspace

dbx:keys=xxx,expires=x,avg_ttl=x:数据库的键数量、带有过期时间的键的数量,存活的时间计数

1.2.10 Commandstats

# Commandstats (执行命令的次数,执行命令所耗费的毫秒数)
cmdstat_replconf:calls=175272,usec=335561,usec_per_call=1.91
cmdstat_command:calls=6,usec=5579,usec_per_call=929.83
cmdstat_set:calls=2117489,usec=8755492,usec_per_call=4.13
cmdstat_auth:calls=417,usec=809,usec_per_call=1.94
cmdstat_zrangebyscore:calls=174,usec=2521,usec_per_call=14.49
cmdstat_latency:calls=1210,usec=2403,usec_per_call=1.99
cmdstat_bgrewriteaof:calls=1,usec=1901,usec_per_call=1901.00
cmdstat_zadd:calls=26908,usec=573861,usec_per_call=21.33
cmdstat_host::calls=16,usec=398,usec_per_call=24.88
cmdstat_zremrangebyscore:calls=2454,usec=14800,usec_per_call=6.03
cmdstat_slowlog:calls=2420,usec=10422,usec_per_call=4.31
cmdstat_info:calls=90152,usec=7952483,usec_per_call=88.21
cmdstat_psync:calls=1,usec=2465,usec_per_call=2465.00
cmdstat_config:calls=1216,usec=101234,usec_per_call=83.25

二、Redis监控工具

2.1 Prometheus+Grafana

  Prometheus可以理解为一个数据库+数据抓取工具,从各节点抓来统一的数据,放入Prometheus这一个时间序列数据库中。那如何保证各处的数据格式是统一的呢?就是通过这个exporter。exporter也是用GO写的程序,它开放一个http接口,对外提供格式化的数据。通过在node节点部署exporter即可实现对Redis的监控。Grafana是一个提供高度可视化的工具,将Prometheus的数据进行可视化展示。
W_SG03K_8H_7_FH_2F4K

2.2 Redis-monitor

  Redis-monitor是由Python编写的开源的图形化监控工具。核心服务部分只包括一个web服务和基于Redis自带的Info命令以及monitor命令的监控服务。支持多实例监控,监控信息可以使用redis存储和sqlite持久化存储。
Y_QCA_Q_T_74_28BU9_D9V

2.3 Redis-stat

  Redis-stat是一个用Ruby编写的简单Redis监控工具,基于Redis的INFO命令,因此与基于MONITOR命令的其他监视工具不同,通常不会影响Redis实例的性能。Redis-stat监视Redis实例在客户端输出,也可以提供Web服务器提供的仪表板页面。

redis-stat  localhost:6379 -a xxx 1 10 --csv=/tmp/output.csv --verbose #客户端输出类vmstat格式的信息
redis-stat --server --daemon #后台运行,在web界面进行输出。

_3HUQIBM9_NW_TYS3JXIM
_0GG_A_ZBHIM_JXOMODTPO0

2.4 Redis-faina

  redis-faina是由Instagram开发并开源的一个Redis查询分析工具。Redis-faina是通过Redis的MONITOR命令来实现的,通过对在Redis上执行的query进行监控,统计出一段时间的query特性。

redis-cli -p 6379 MONITOR | head -n | ./redis-faina.py [options] #Redis-faina对MONITOR的输出文件进行分析展示

  输出格式如下

Overall Stats
========================================
Lines Processed      7904
Commands/Sec         256.80

Top Prefixes
========================================
n/a

Top Keys
========================================
970125      3952    (50.00%)
aaa850      2       (0.03%)
aaa919      2       (0.03%)
aaa852      2       (0.03%)
aaa853      2       (0.03%)
aaa678      2       (0.03%)
aaa679      2       (0.03%)
aaa856      2       (0.03%)

Top Commands
========================================
AUTH      3952    (50.00%)
set       3950    (49.97%)

Command Time (microsecs)
========================================
Median      1920.0
75%     2016.25
90%         2092.0
99%         2840.0

Heaviest Commands (microsecs)
========================================
AUTH      22542297.5
set       8236623.75

Slowest Calls
========================================
20718202.0      "AUTH" "970125"
8456.0          "set" "aaa82" "aaaaaaaa82"
6624.0          "set" "aaa103" "aaaaaaaa103"
6506.0          "set" "aaa817" "aaaaaaaa817"
6105.0          "set" "aaa2024" "aaaaaaaa2024"
6081.0          "set" "aaa1057" "aaaaaaaa1057"
6074.75         "set" "aaa1948" "aaaaaaaa1948"
6067.0          "set" "aaa576" "aaaaaaaa576"

三、Redis性能优化

3.1 慢查询

  通常来讲,时间复杂度是O(1)的命令是安全的,时间复杂度是O(N)命令在使用时需要注意,避免在使用这些O(N)命令时发生问题主要有几个办法:

  • 不要把List当做列表使用,仅当做队列来使用。
  • 通过机制严格控制Hash、Set、Sorted Set的大小。
  • 可能的话,将排序、并集、交集等操作放在客户端执行。
  • 绝对禁止使用KEYS命令。
  • 避免一次性遍历集合类型的所有成员,而应使用SCAN类的命令进行分批的,游标式的遍历。

3.2 网络延迟

  • 尽可能使用长连接或连接池,避免频繁创建销毁连接。
  • 客户端进行的批量数据操作,应使用管道完成。

3.3 数据持久化引发的延迟

  • AOF + fsync always的设置虽然能够绝对确保数据安全,但每个操作都会触发一次fsync,会对Redis的性能有比较明显的影响。
  • AOF + fsync every second是比较好的折中方案,每秒fsync一次。
  • AOF + fsync never会提供AOF持久化方案下的最优性能。
  • 使用RDB持久化通常会提供比使用AOF更高的性能,但需要注意RDB的策略配置。
  • 每一次RDB快照和AOF Rewrite都需要Redis主进程进行fork操作。fork操作本身可能会产生较高的耗时,与CPU和Redis占用的内存大小有关。根据具体的情况合理配置RDB快照和AOF Rewrite时机,避免过于频繁的fork带来的延迟。

3.4 大对象和大键/键个数和长度的突增

  • 尽量只用小的KEY,并且KEY要有可读性,严格控制Value的大小。

3.5 数据淘汰引发的延迟

  • 当同一秒内有大量key过期时,也会引发Redis的延迟。在使用时应尽量将key的失效时间错开。

3.6 引入读写分离机制

  Redis的主从复制能力可以实现一主多从的多节点架构,在这一架构下,主节点接收所有写请求,并将数据同步给多个从节点。在这一基础上,可以让从节点提供对实时性要求不高的读请求服务,以减小主节点的压力。尤其是针对一些使用了长耗时命令的统计类任务,完全可以指定在一个或多个从节点上执行,避免这些长耗时命令影响其他请求的响应。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章