Redis集群性能问题深度分析

Redis集群性能问题深度分析

参考

Redis开发与运维

https://redis.io/

http://www.redis.cn/

https://github.com/antirez/redis

https://github.com/sohutv/cachecloud

源起

优化之路永无止境,在此之前一做过一些架构优化汇总如下:

1,Redis集群3.0.7升级到3.2.9解决读从节点KEY过期不删除问题,集群有几千万KEY原来经核查3.0.7版本只有主上保存过期时间,所以需要主触发才能删除过期的KEY,默认有主动删除与惰性删除同时工作,但是KEY比较多,写的比删除的KEY,另外读从的话不能触发主动删KEY所以会有KEY没更新问题,升级3.2.X之后解决。

2,发现持久化操作时容易导致超时,后来从节点的持久化关闭,效果良好;后续计划持久化非持久化业务分开,过期时间短的与过期时间长的分开。

2,集群扩容,升级到3.2.9版本后为了均摊QPS扩容了几个节点,后续发现有2个节点内核版本比其他的高但是性能反而表现比其他差,后替换了同版本的内核。

3,Bigkeys扫描发现有几个hashkey元素过大超过几千万,单个KEY占用内存几个G后联系开发解决。

4,建立了CacheCloud监控系统,便于分析观察问题,另外Zabbix也使用Redis模版出现大故障时会报错。

5,后续优化方向转为客户端使用规划的问题,主要是解决各个量大的命令平均用时超过10微秒的问题。

6,每个Redis集群版本升级在功能与性能上都有比较大的提升,需要持久化功能的集群后续可以使用4.0.2版本,另外如果使用虚拟化不建议使用XEN、Hyper-V等,最好使用vSphere压力测试vSphere在各方面表现良好。

一,发现问题

1,慢查询

slowlog get n 默认保留128个日志执行超过10毫秒的记录,可以根据实际情况修改

2,应用报错

主要是应用邮件报超时

二,分析问题

1,内在原因

1)API或数据结构使用不合理

2)CPU饱和的问题

3)持久化相关的阻塞

2,外在原因

1)CPU竞争

2)内存交换

3)网络问题

三,解决问题之内在原因

1,API或数据结构使用不合理

1)发现慢查询

slowlog get n

慢查询日志有两个参数:

slowlog-log-slower-than: 单位微妙,指定redis执行命令的最大时间,超过将记录到慢查询日志中, 不接受负值,如果设置为0每条命令都要记录到慢查询日志中,默认10微妙。

slowlog-max-len: 设置慢查询日志长度,如果慢查询日志已经到最大值,如果有新命令需要记录,就将最老那条记录删除,默认保存128,可以在线修改,CONFIG REWRITE保存。

redis-cli 

127.0.0.1:6379> config get slowlog-max-len

1) "slowlog-max-len"

2) "128"

127.0.0.1:6379> config set slowlog-max-len 1000

OK

127.0.0.1:6379> config rewrite

OK

2)发现大key

redis-cli --bigkeys

2,CPU饱和

1)统计Redis状态

500QPS左右,单个命令使用时间越少支持的QPS并发越大,比如平均1毫妙的支持1000QPS,平均100微妙的支持10000QPS。

redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections          
5088981    6.51G    514     0       578132987 (+0)      384742      
5088997    6.51G    514     0       578133573 (+586)    384742      
5089018    6.51G    514     0       578134096 (+523)    384742      
5089005    6.51G    515     0       578134720 (+624)    384743      
5089048    6.51G    515     0       578135195 (+475)    384743      
5089093    6.51G    513     0       578135829 (+634)    384743      
5089117    6.51G    513     0       578136455 (+626)    384743      
5089081    6.51G    512     0       578136850 (+395)    384743      
5089121    6.51G    512     0       578137226 (+376)    384743

2)命令统计

时间单位为微秒

单个命令10微妙以内,尽量避免高算法复杂的命令

setex平均26

del  平均43

hmset平均229

hmget平均12

以上特别是hmset要优化,另外hgetall命令不建议使用

redis-cli  info commandstats
# Commandstats
cmdstat_get:calls=2814596805,usec=12130889716,usec_per_call=4.31
cmdstat_set:calls=25674338,usec=234328226,usec_per_call=9.13
cmdstat_setex:calls=910333006,usec=20767349072,usec_per_call=22.81
cmdstat_del:calls=780287520,usec=33983500560,usec_per_call=43.55
cmdstat_lpush:calls=1,usec=34,usec_per_call=34.00
cmdstat_hset:calls=145663119,usec=499130659,usec_per_call=3.43
cmdstat_hget:calls=2841141555,usec=13763160250,usec_per_call=4.84
cmdstat_hmset:calls=1452658,usec=333516295,usec_per_call=229.59
cmdstat_hmget:calls=970024532,usec=11909915205,usec_per_call=12.28
cmdstat_hdel:calls=581004,usec=3925702,usec_per_call=6.76
cmdstat_hgetall:calls=28985688,usec=555451600,usec_per_call=19.16
cmdstat_hexists:calls=262547,usec=2867627,usec_per_call=10.92
cmdstat_select:calls=1,usec=1,usec_per_call=1.00
cmdstat_expire:calls=72409493,usec=101731304,usec_per_call=1.40
cmdstat_auth:calls=1544789,usec=2890530,usec_per_call=1.87
cmdstat_ping:calls=4977672,usec=2672430,usec_per_call=0.54
cmdstat_echo:calls=697770,usec=380462,usec_per_call=0.55
cmdstat_info:calls=32700948,usec=7243085428,usec_per_call=221.49
cmdstat_config:calls=2176619,usec=31168795,usec_per_call=14.32
cmdstat_subscribe:calls=1717,usec=7283,usec_per_call=4.24
cmdstat_unsubscribe:calls=5506966,usec=21985846,usec_per_call=3.99
cmdstat_cluster:calls=696482,usec=210160284,usec_per_call=301.75
cmdstat_readonly:calls=696449,usec=437883,usec_per_call=0.63
cmdstat_client:calls=697770,usec=1869891,usec_per_call=2.68
cmdstat_slowlog:calls=2,usec=214,usec_per_call=107.00
cmdstat_command:calls=2,usec=11824,usec_per_call=5912.00

3)持久化阻塞

由于从已经关闭持久化,主要分析主的,主上只开启了RDB且10分钟一次,没有开启AOF刷盘阻塞(故不用考虑)

fork阻塞:latest_fork_usec该指标不能超过1秒,这里是275毫秒

redis-cli  info stats
# Stats
total_connections_received:384861
total_commands_processed:578276973
instantaneous_ops_per_sec:509
total_net_input_bytes:530863235402
total_net_output_bytes:1584445816901
instantaneous_input_kbps:668.38
instantaneous_output_kbps:838.84
rejected_connections:0
sync_full:1
sync_partial_ok:0
sync_partial_err:0
expired_keys:164683638
evicted_keys:0
keyspace_hits:193101765
keyspace_misses:12414607
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:275078   275毫秒
migrate_cached_sockets:0

另外HugePage写操作阻塞,这个内核已经关闭HugePages,方法如下

echo never > /sys/kernel/mm/transparent_hugepage/enabled

四,解决问题之外在原因

1,CPU竞争

Redis是典型的CPU密集型应用,同一台服务器不建议部署其他服务,如果需要不是多个Redis实例也建议绑定CPU。

2,内存交换

1)根据进程号cat /proc/5413/smaps |grep Swap可以查看内存交换,为了避免内存交换,首先服务器最好富余1/3-1/2内存,fork时会生成一个进程占用当前实例大小的内存,等于说内存加倍。

2)设置最大可用内存及触发内存启动lru算法(Redis版本越高该算法效率越高,因为Redis一直在进化)以防万一,方法如下:

127.0.0.1:6379> CONFIG GET maxmemory

1) "maxmemory"

2) "21474836480"

127.0.0.1:6379> CONFIG GET maxmemory-policy

1) "maxmemory-policy"

2) "allkeys-lru"

3)可以降低系统使用swap的优先级,由于前面对内存做了优化这里没有对swap调优,毕竟这些都是不得已手段,需要从架构与使用上修改效果才好。

3,网络问题

1)连接拒绝

主要是网络闪断接Redis连接数超过默认的10000,可以通过监控与修改默认值规避。目前连接不多,如果连接过多服务端的timeout可以修改一个具体的值,默认是0代表永远不主动断开连接。

另外连接溢出,这个服务端与客户端都需要排查,主要是看进程限制与backlog队列是否溢出。

2)网络延迟

3)网卡软中断

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏散尽浮华

由索引节点(inode)爆满引发的问题

关于磁盘空间中索引节点爆满的问题还是挺多的,借此跟大家分享一下: 一、发现问题 在公司一台配置较低的Linux服务器(内存、硬盘比较小)的/data分区内创建...

35480
来自专栏枕边书

PHP 调用 Go 服务的正确方式 - Unix Domain Sockets

问题 可能是由于经验太少,工作中经常会遇到问题,探究和解决问题的过程总想记录一下,所以我写博客经常是问题驱动,首先介绍一下今天要解决的问题: 服务耦合 我们在开...

394110
来自专栏JAVA烂猪皮

大型分布式网站架构:缓存在分布式系统中的应用

缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题。提供高性能的数据快速访问。

18030
来自专栏北京马哥教育

10分钟带你光速入门运维工具之-Puppet

一、简介 当服务器数量达到一定的规模时,仅依靠人为完成批量部署服务器个资源的配置,运维工作将变得繁琐且容易出错,为了解决这一问题,我们应该怎么办呢?我们可以引...

487110
来自专栏进击的程序猿

ZooKeeper: Wait-free coordination for Internet-scale systems(笔记)

本文是读ZooKeeper: Wait-free coordination for Internet-scale systems的笔记,从第一手资料了解zook...

12630
来自专栏北京马哥教育

10分钟带你光速入门运维工具之-Puppet

一、简介 当服务器数量达到一定的规模时,仅依靠人为完成批量部署服务器个资源的配置,运维工作将变得繁琐且容易出错,为了解决这一问题,我们应该怎么办呢?我们可以引...

36860
来自专栏IT技术精选文摘

缓存在分布式系统中的应用

缓存是分布式系统中的重要组件,主要解决高并发,大数据场景下,热点数据访问的性能问题。提供高性能的数据快速访问。 一、缓存概述 缓存是分布式系统中的重要组件,主要...

37790
来自专栏IT技术精选文摘

redis架构演变与redis-cluster群集读写方案

redis-cluster是近年来redis架构不断改进中的相对较好的redis高可用方案。本文涉及到近年来redis多实例架构的演变过程,包括普通主从架构(M...

71030
来自专栏无题

读曾宪杰《大型网站系统与Java中间件实践》

十年,一个时代过去 1.分布式系统相对集中式而言,是指多台计算机互相通过消息通信进行协作而对外提供服务;可解决大型机的伸缩性和单点等问题; 2.网络i/o有b...

32950
来自专栏三杯水

Redis集群性能问题深度分析

Redis开发与运维 https://redis.io/ http://www.redis.cn/ https://github.com/antirez/...

1K10

扫码关注云+社区

领取腾讯云代金券