阿里云Redis百万千万读写慢排查实战

文章描述了一次通过监控工具Prometheus和Grafana发现Redis写入数据缓慢的问题,分析了网络带宽、延迟等因素,并在阿里云环境中找到问题根源——跨可用区导致的高延迟。通过迁移RDS到相同可用区,成功解决了性能问题。
摘要由CSDN通过智能技术生成

背景

20万数据 100M,单条平均大小100K写入redis花费6-8分钟,计算一下NetWork有多少,公式2:100 *1024 KB/360S=284KB/S,发现只有这么点,验证实际是否这样,通过Prometheus+Grafana监控导入dashboard插件 redis和redis time streaming

安装监控

本地安装prometheus+grafana

如果已经安装或者开发测试环境已安装请忽略这一步,下载docker,mac电脑可以使用brewinstall docker或者去官网

Install Docker Desktop on Mac

Docker加速镜像配置

配置文件:

加速镜像配置地址:~/.docker/daemon.json;内容如下:

{

"builder": {

"gc": {

"defaultKeepStorage":"20GB",

"enabled": true

}

},

"experimental": false,

"features": {

"buildkit": true

},

"registry-mirrors": [

"https://52msq4gm.mirror.aliyuncs.com"

]

}

启动prometheus

docker run -d--restart=always

-p 9090:9090 -v /XX/prometheus.yml:/etc/prometheus/prometheus.ymlprom/Prometheus

启动grafana

docker run -d \

-p3000:3000 \

--name=grafana \

-v/opt/grafana-storage:/var/lib/grafana \

grafana/Grafana

Docker 重新启动命令

docker restartgrafana

docker restartprometheus

进入grafana控制台配置Redis的DataSource;

安装 redis plugins

配置redis dataSource

下载grafana模版

进入grafana dashboard官网下载模版,Dashboards | Grafana Labs datasource选择redis,把这下个下载json

搜索redis dashboard

下载json文件

Grafana配置导入redis监控模版

配置好后进入redis dashboard

Redis

Redis stream

问题分析

grafana监控

根据grafana监控 NetWork指标曲线 200~300KB/s(假装上面截图是,当时测试没有截图,懒得在跑一遍)

计算300KB/s 100M数据需要多久,公式:100 * 1024 KB/300KB/60S=5.6分钟

计算写入6分钟写入100M数据是多少NetWork,公式2:100 * 1024 KB/360S=284KB/S

影响redis性能原由

综上所述,这个写入redis是非常慢的,有很大的问题;影响redis的性能可能原因如下:

  1. 网络带宽和延迟通常是最大短板;在小对象存取时候,内存速度和带宽看上去不是很重要,但是对大对象(>10 KB), 它就变得重要起来

  1. CPU 是另外一个重要的影响因素,由于是单线程模型,不需要多核,但需要单核能力强的,如使用Intel CPU,而不用AMD CPU

排查与实践

  1. 先查看redis带宽,我们是买的阿里云的,寻求运维同学查看一下阿里云控制台,发现生产是80MB/s,测试时20MB/s,看了配置也没有限制,那肯定不是带宽的问题

  1. 测试生产延迟,到生产pod里使用ping阿里云VIP地址,发现是192网段这个应该是内网,为了验证没有幺蛾子本地ping一下192地址发现ping不通,确定是走的内网,那就不应该既然走了内网且应用是部署在K8S也是在同一个地区的,不存在网络问题的,但是继续往下看发现ping的延迟是1ms,对于同区网络下应该不会这么高的,为了验证继续看看测试环境是否一样这样。

  1. 测试测试环境延迟,其他都跟生产一样,测试ping的是172网段是内网,但是发现延迟确是0.1ms相差了10-20倍,估计问题就是在这里了;估摸着折算到实际写入数据到redis估算应该是不会有这么大,应该会5倍左右提升

  1. 问题找到后,赶紧再次联系运维,怀疑是阿里云redis服务相关问题,向阿里云发起工单;给予解释是:阿里云上应用的K8S集群与RDS如果是同可用区则是小于1ms延迟,跨可用区则是小于3ms延迟;最终让运维检查发现生产K8S集群是在可用区I,生产RDS购买在了可用区H;又检查了测试环境K8S集群是在H区,测试RDS购买在了可用区H;所以结论是符合阿里云说的延迟的

生产实例,Ping信息:

测试实例,Ping信息:

阿里云工单聊天记录:

解决方案

  1. 迁移RDS可用区(推荐,我们是选这个方案,在阿里云上迁移一下就行; )

  1. K8S集群新构建与RDS一样的H区,应用发到新K8S集群

我们后台页面

优化前spring batch表执行情况

优化后spring batch表执行情况

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值