一次缓存性能问题排查

发布时间:2020-06-23 12:39:57 作者:乐少黑板报
来源:网络 阅读:481

概述

以下分享的都跳过了很多坑,包括redis、tomcat环境配置、机器硬件配置等等问题(与线上保持一致,或者硬件性能减配系数,例如线上:8C16G,压测:4C8G,系数简单相差2倍),直接把挖掘瓶颈的主要思路搬出台面。

压测数据分析

全局图预览

一次缓存性能问题排查cdn.xitu.io/2018/11/29/1675ebca0b8bfcb2?w=1919&h=880&f=png&s=125839">


一次缓存性能问题排查      


通过对某直播观看页面进行高并发压测,在APM(Pinpoint)监控中发现一个有趣的地方:

一次缓存性能问题排查      

上图中两个红框中的数据(接近10s),相隔大概30分钟就发生,16:20左右,系统撑不住服务出现异常不可用,怀着好奇的心态,追查方法调用的栈,如下图所示:

一次缓存性能问题排查      

该方法耗时多久呢?首先搞清楚Call Tree里面的一些概念:

一次缓存性能问题排查      

可见这个sql查询方法耗时14秒多,为什么呢?APM里面已经显示了sql语句,在mysql中执行查询发现执行时间很快,那么问题出在哪里呢?只能继续深挖!

通过对比同样的url,请求响应毫秒级的情况下,发现数据如下图所示:

一次缓存性能问题排查      

从redis获取到数据后,并没有再执行sql查询了,通过这个分析,我们决定追踪代码还原真相(不懂代码的测试不是好开发):

一次缓存性能问题排查      

一次缓存性能问题排查      

可以看到缓存失效之后,直接查询数据库了

解决方案

SQL优化:优先级低

从数据分析来看,sql优化的用处不大,并不是返回了大量数据缺少索引,此次可以跳过。

缓存并发:优先级高

  出现场景:当网站并发访问高,一个缓存如果失效,可能出现多个进程同时查询DB,同时设置缓存的情况,如果并发确实很大,这也可能造成DB压力过大,还有缓存频繁更新的问题。
  处理方法:对缓存查询加锁,如果KEY不存在,就加锁,然后查DB入缓存,然后解锁;其他进程如果发现有锁就等待,然后等解锁后返回数据或者进入DB查询。



经验总结

1、善用监控工具,例如APM,进行链路监控、服务器性能、方法调用顺序观察

2、追踪方法栈和相关日志

3、深入排查代码挖本质


微信公众号:乐少黑板报



推荐阅读:
  1. LAMP+Memcached高性能缓存服务
  2. 一次docker-compose升级问题排查

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

性能 软件测试

上一篇:JavaScript中方法的实际应用

下一篇:PingHurry Portable - Adminscope,多功能ping工具

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》