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

---

theme: orange

一、背景

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

image.png

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

image.png

二、排查与沟通过程

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

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

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

和dba进行了沟通，dba给了我们两条建议：

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

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

三、第一次优化

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

image.png

四、第二次优化

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

我们需要解决的问题：

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

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

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

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

image.png

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

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

image.png

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

image.png

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

image.png

五、测试与上线流程

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

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

• 2、灰度验证

• 3、分机器发布

• 4、全量发布

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

六、最终效果

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

image.png

七、总结

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

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

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

image.png

本文由 mdnice 多平台发布