Codis响应超时分析

可能引起Codis堵塞的几个因素:

超大key,且频繁调用,造成网络堵塞

慢查询,拖慢Redis命令执行效率

持久化、主从全量同步导致Redis夯住

虚拟机Redis固有延迟过大、透明大页、内存申请策略

过期key清除数量过大,或者超大key过期,导致Redis堵塞

QPS过高或集群访问压力过大

proxy的GC负载导致proxy服务卡顿

网络延迟

超大key

2017.09.29,出现过一次由于超大key(String类型,value大小 30M)导致的超时问题,清除大key后超时问题就没再出现了;

Codis响应超时分析_第1张图片
删除超大key后网络流量的变化

怀疑是超大key导致,于是将所有codis-server节点的数据导出分析,并未发现有过大的key,且codis-server的网络流量也很低;

慢查询

慢查询是最显而易见会拖慢Redis执行效率导致响应超时的;

在出现大面积响应超时时,检查codis-server的慢查询,并未发现有慢查询记录(默认的慢查询阈值为10ms,即某一个请求Redis处理的耗时为10ms,不包括网络传输);

将所有codis-server节点的慢查询阈值调整到1ms,发现业务1方的zset集合由于集合基数达到了1万多(当时的基数,现在有12万),有比较多超过1ms的操作:

于是将业务1的10个zset集合所在的分片,迁移至单独的codis-server节点,如确实会堵塞Redis的话,也只会堵塞这一个codis-server节点,但是事实证明,迁移完成后问题还是没得到缓解;

持久化、主从全量同步

生产环境Codis的持久化配置为主不持久化,从节点开启RDB持久化,读写都在主节点;

主节点不持久化就不会影响读写,那么大面积超时的时候主从并没有发生全量同步,也不会造成redis堵塞;

虚拟机固有延迟

Redis官方文档说明如下:

If you are using a virtual machine, it is possible that you have an intrinsic latency that has nothing to do with Redis. Check the minimum latency you can expect from your runtime environment using ./redis-cli --intrinsic-latency 100. Note: you need to run this command in the server not in the client.

Redis,在虚拟机环境下,本身就会有一个固有延迟(从接收命令到CPU处理完命令);

对每一个codis-server节点进行固有延迟测试,发现某几个机器的延迟特别大,如下:

Codis响应超时分析_第2张图片
某两个codis-server节点的固有延迟

将测试出固有延迟的节点机器替换掉,问题依旧;

过期key清除数量太大、超大key过期

Redis的过期key清除策略有3钟:被动删除、主动删除、超过maxmemory后触发主动清理策略(LRU),不管是哪种策略都会执行del命令,Redis是有记录的,如下(单位:us):

Codis响应超时分析_第3张图片
命令执行耗时记录

可以看到del命令,耗时很小,排除过期key删除的原因;

QPS过高、集群访问压力问题

集群1的QPS在每秒1万左右,实际并不高,担心访问压力导致的堵塞,尝试增加codis-server节点,从6主6从增加到8主8从,问题依旧;

集群拆分:业务2使用codis最频繁,于是从之前的8主8从集群中拆分一个4主4从的集群只供业务2使用,拆分后,集群1的流量减少一半,和业务2集群持平,但是第二天依旧是两个集群都有严重超时;

proxy的GC频率

go version 1.8.1,启动proxy时开启GC日志采集,分析日志发现GC并无异常;

网络延迟

一开始怀疑过网络问题,但是前期抓包并没有分析出问题原因,且都是内网交互,千兆网卡,理论上是不会有网络瓶颈的;

于是使用redis-cli自带的交互延迟测试工具采集数据如下:

Codis响应超时分析_第4张图片
不同节点之间的延迟对比

采集到的数据比对后,发现proxy到codis-server之间有的会存在很大的延迟,但并不是每两两节点交互都会有很大延迟;

编写简单的TCP echo server,检测延迟较大的两个节点之间的网络延迟,发现某些时刻,延迟确实很大,如下:

Codis响应超时分析_第5张图片
简单的TCP echo server耗时结果统计

在问题最严重的两天,每天下午4点开始持续抓包分析,发现存在大量的重传和丢包;

于是回头去检查因为合规在机房新加的两个机柜之间的网络布线,发现新机柜和老机柜之间存在跳线,而正好因为合规,codis的部分节点迁移到了新机柜上;

将新存在跳线的codis节点,迁移到老机柜上,问题未在复现;

至此,codis响应超时问题,解决!

改进方案

数据结构优化,减少慢查询发生的概率,如:spring-session里面用到的hgetall、smembers,业务1里的 大基数zset;

codis-proxy和codis-server节点均升级为物理机,降低codis节点的固有延迟,让其独享网络和IO,全面提升节点的各方面性能;

你可能感兴趣的:(Codis响应超时分析)