写点什么

记录线上数据库飙升到 60 的性能优化

作者:奔跑吧!
  • 2024-05-26
    上海
  • 本文字数:1259 字

    阅读完需:约 4 分钟

记录线上数据库飙升到60的性能优化

一、背景

有一天,dba 在数据库告警群找到我,说我们数据库 CPU 有规律性的尖刺,qps 每次突然增加 500+,尖刺时 cpu 飙升到 60%,没尖刺时只有 5%左右



这种情况对系统造成的稳定性风险极高,要我们尽快排查,尽早排除隐患。下面是当时的数据库 qps 监控



二、排查与沟通过程

由于是规律性的尖刺,我们想到我们的定时job, 我们业务有一个业务配置缓存数据,通过 Java 程序的定时 job 从数据库加载到本地内存的,而且时间也吻合。


通过查看代码,我们是一个单机的 job 每,5 分钟加载一次,每台机器都是分页从数据库读取配置数据,每次读取100条,然后写到本地的内存里。


这里有两个问题,单机的 job 和分页查询,我们生产环境有 50 台机器,这样查询db的qps会放大,造成数据库压力扩大。


和 dba 进行了沟通,dba 给了我们两条建议:


1、要我们不要分页查询,直接一次性查询所有的配置数据。


2、不要用本地缓存,直接使用 redis,这样就一份数据,操作数据库的 qps 也降低了。

三、第一次优化

由于是 c 端系统,而且业务配置缓存是系统的热点数据,考虑到系统稳定性第一,我们第一次没有大的改动,试图调高了分页的limit大小,观测数据库的监控,cpu 使用率有下降,但是还是有尖刺,这样还有慢sql情况。



四、第二次优化

由于尖刺仍然存在,对数据库还是有一定的压力,且现在的方案存在优化空间,为了彻底消除数据库隐患,因此我们开始了第二轮优化。


我们需要解决的问题:


1、降低数据库qps,消除cpu尖刺


2、不影响查询热点配置数据的性能


因为每台机器都请求数据库,分页查询请求,我们想着降低请求 qps,因此我们去除原来这种单机定时加载缓存方式,换成加载缓存到 redis,这样就只要一台机器启动一个定时任务了,这样可以降低数据库的 qps。由一个定时任务每 5 分钟执行一次,加载到 redis。


不影响原来的查询性能,肯定不能直接查询 redis,因此我们引入了本地缓存框架Caffine,本地缓存从 redis 查询数据。这样就形成了二级缓存架构



整个缓存改造涉及三个阶段:


第一阶段:使用xxljob定时 job 加载缓存到 redis



第二阶段:程序启动初次加载缓存,加载数据到本地缓存



第三阶段:Caffine 缓存未命中场景,单线程从缓存或者数据库加载



五、测试与上线流程

这次属于技术升级,需要测试回归相关业务才能上线,整体测试与上线流程如下:


  • 1、测试回归业务功能,开关验证

  • 2、灰度验证

  • 3、分机器发布

  • 4、全量发布


先发布一台机器节点,观测了几天业务情况,观测没问题之后再分批次发布,直到所有机器节点发布完成。

六、最终效果

经过优化上线,数据库的 qps 和 cpu 使用率下来了,也没有了尖刺,彻底消除了数据库隐患。


七、总结

数据库是业务系统强依赖的中间件,保障其稳定性至关重要,本文是根据实际性能优化经验,从架构设计代码层面优化数据库的使用,降低数据库 qps 和 cpu 使用率,提高数据库的稳定性


通过这次优化实践,给以后业务功能的设计开发也有一定的启发,一个好的方案设计可以避免系统风险,提高资源利用率,作为程序员可以利用每次新功能的设计开发经验,不断的积累比较好的方案,提升我们自身的能力。


坚持相信有输入一定要有输出,我们一起学习沉淀技术,希望我们的技术能力越来越强。


发布于: 刚刚阅读数: 4
用户头像

奔跑吧!

关注

有输入必须要有输出! 2019-07-22 加入

Dubbo贡献者,精通Java技术栈,8年互联网平台系统研发与管理经验

评论

发布
暂无评论
记录线上数据库飙升到60的性能优化_性能优化_奔跑吧!_InfoQ写作社区