记一次线上Redis高负载排查经历
作者:JingQ
https://www.sevenyuan.cn/
周一早上刚上班,突然大量用户反馈进入网页很慢,登录服务器一看,Redis调用时间严重超时,这样高速的缓存反而变成了短板,由于数据一直没有返回,导致了请求响应变慢。
网页监控
通过阿里的 Grafana 监控,服务器的 CPU 负载、内存、网络输入输出都挺正常的,所以肯定是 Redis 出现了问题。
我们应用使用的是单节点的 32M 16GB 的阿里云 Redis,登录网页监控看性能监控,发现 CPU 使用情况飙升到100%!!!
QPS 虽然从 1000 多升到 6000,但是远远低于极限值,连接数量从 0 升到 3000,也是远远低于极限值(可能用户刚上班,开始有请求,然后响应延迟,导致命令队列数量过多,打开很多连接)。
临时方案:先租用一台新的 Redis 服务器,更换应用服务器的 Redis 配置,重启应用,避免影响更多用户。
然后我们继续跟踪 Redis 的具体情况。
服务器命令监控
登录 Redis-cli,通过 info 命令查看服务器状态和命令统计,祥哥总结了两点异常点:
查询 redis 慢指令 slowlog,排行前十的指令均为’keys _‘,并且耗时严重,在当前业务流量下执行’keys _‘,一定会阻塞业务,导致查询慢,cpu 高的。值得注意的是应用层面没有开放 ‘keys *’ 接口,不排查有后台人为或后台程序触发该指令。
查看 redis 指令执行情况,排除 ‘exec’,’flushall’ 等指令,业务使用指令中,耗时严重的有 setnx 有7.5千万次调用平均耗时 6s,setex 有8.4千万次调用平均耗时7.33s,del 有2.6亿次调用平均耗时69s,hmset 有1亿次调用平均耗时 64s,hmget 有6.8千万次调用平均耗时 9s,hgetall 有14亿次调用平均耗时 205s,keys 有2千万次调用平均耗时 3740s。
通常而言,这些指令耗时与 value 大小呈正比,所以可以排查这些指令相关的数据近期有没有较大增长。或者近期有没有业务改造,会频繁使用上述指令,也会造成 cpu 高。
(当时忘了截图,下图只是展示命令和参数含义)
通过 info commandstats 可以查看 Redis 命令统计信息,其中命令格式是
cmdstat_XXX: calls=XXX,usec=XXX,usec_per_call=XXX
调用次数、耗费CPU时间、每个命令平均耗费CPU(单位为微秒)
通过 slowlog 命令查看慢命令(默认超过 10ms 就会被记录到日志,只会记录其命令执行的时间,不包含 IO 往返操作,也不记录单由网络延迟引起的响应慢)
(当时也忘了截图,所以就介绍一下 slowlog 怎么看)
xxxxx> slowlog get 103) 1) (integer) 411 2) (integer) 1545386469 3) (integer) 232663 4) 1) "keys" 2) "mecury:*"
图中各字段表示的是:
1=日志的唯一标识符
2=命令的执行时间点,以UNIX时间戳表示
3=查询命令执行时间,以微妙为单位,????中的是230ms
4=执行的命令,以数组的形式排列。完整的命令是 keys mucury:*
所以通过这些参数,基本可以确定,是突然有大量的keys *
命令导致CPU负载升高,导致响应延迟,问题我们应用中没有开放keys *
命令Σ(o゚д゚oノ)
最后将这些统计结果和慢命令发到研发群,发现是别的应用配置配成了我们的Redis,然后他们有个业务场景是爬数据,突然涌入大量的调用,不断的keys *,导致我们的Redis不堪重负,于是将配置修改正确,不再调用我们的Redis。
总结
Redis 抖动可以先看网页监控(阿里云做的真好!)
通过命令查看 Redis 指令状态和慢命令的情况
考虑优化 Redis 在代码中的使用情况
如果流量继续上升,需要考虑一下升级了=-=
参考文章
Redis性能问题排查解决手册(七)
redis info command
END
推荐好文
强大,10k+点赞的 SpringBoot 后台管理系统竟然出了详细教程!分享一套基于SpringBoot和Vue的企业级中后台开源项目,代码很规范!
能挣钱的,开源 SpringBoot 商城系统,功能超全,超漂亮!
记一次线上Redis高负载排查经历相关推荐
- 线上Redis高并发性能调优实践
点击上方关注 "终端研发部" 设为"星标",和你一起掌握更多数据库知识 作者 | 丶谦信 来源 | urlify.cn/YBJryu 66套java从入门到 ...
- 记一次线上redis报错(JedisExhaustedPoolException: Could not get a resource since the pool is exhausted)
错误详情 redis.clients.jedis.exceptions.JedisExhaustedPoolException: Could not get a resource since the ...
- Redis高负载排查记录
Redis简单运维学习 周一早上刚上班,突然大量用户反馈进入网页很慢,登录服务器一看,Redis调用时间严重超时,这样高速的缓存反而变成了短板,由于数据一直没有返回,导致了请求响应变慢. 网页监控 通 ...
- Redis 高负载排查记录
来源:https://www.sevenyuan.cn/ 周一早上刚上班,突然大量用户反馈进入网页很慢,登录服务器一看,Redis调用时间严重超时,这样高速的缓存反而变成了短板,由于数据一直没有返回, ...
- 记一次线上服务假死排查过程
大家好,我是烤鸭: 最近线上问题有点多啊,分享一个服务假死的排查过程. 问题描述 9点10分,收到进程无响应报警(一共6台机器,有1台出现),后来又有1台出现. 排查思路 首先确认是否误报或者网络抖动 ...
- 记一次线上环境 redis偶尔连接超时报错 解决
记一次线上环境 redis偶尔连接超时报错 解决 贴出本地控制台日志 说实话,很痛苦,跟进很久了,一直认为的jvm程序所使用的配置的连接池框架问题 因为程序为 springboot 2 spring ...
- 线上服务器CPU负载过高的问题解决过程
线上服务器CPU负载过高的问题解决过程 一.找到CPU占用过高进程 执行top命令,发现PID为12443的Java进程占用CPU高达350%,出现故障. 二.定位具体线程或代码 找到该进程后,接下来 ...
- 线上Java 高CPU占用、高内存占用排查思路
一.前言 处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题.当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警.本文主要针对系统 ...
- 记几次 [线上环境] Dubbo 线程池占满原因分析(第三次:GC STW)
[线上环境] Dubbo 线程池占满原因排查系列 记几次 [线上环境] Dubbo 线程池占满原因分析(第一次:HttpClient) 记几次 [线上环境] Dubbo 线程池占满原因分析(第二次:C ...
最新文章
- 零基础python从入门到精通 pdf-跟老齐学Python从入门到精通 电子版(pdf格式)
- 论文笔记 OHEM: Training Region-based Object Detectors with Online Hard Example Mining
- 缩影和掠影_普查员的“酸苦甜” 社区人口普查工作掠影
- 我是大道至简山寨版~
- Non-Rigid Registration Under Isometric Deformations
- 抖音上python有用吗_专栏 | 如何在抖音上找到漂亮小姐姐?这里有个Python抖音机器人...
- 遥感、GIS及GPS 土壤普查、制图及土壤空间数据分析
- 维修记录java_维修保养记录
- 机器学习中的数学——距离定义(一):欧几里得距离(Euclidean Distance)
- 投入产出表分析(交通经济学作业)
- 微信小程序制作——获取用户信息
- 旅客因航班耽搁殴打工作职员被拘
- 金字塔图像融合方法总结(一)
- 玲听预告 | 蚂蚁金服布局区块链的底层心法是什么?
- 红米手机怎么把软件移到sd卡
- 批量转换灰度图并保存
- [Apple Shapr3D]【续更】【shapr3D】认识Shapr3D,一个简单易用的设计类软件
- [激光原理与应用-41]:《光电检测技术-8》- 白光干涉仪
- C++ —— 自定义函数
- python怎么自学