数据库CPU占满100%了？？？

看着眼前异常飙升的CPU占有率，某地铁客户（TOP5级）核心业务系统CLC（多线路集中管理系统）的运维人员小明发出一阵惊呼。

交易结算系统页面白屏卡顿，产生大量超时等待，一查监控，数据库CPU占用竟已达到100%！小明大惊失色，该项目从2022年上线至今已运行两年多时间，接入线网车站将近400个，实际还有将近100个既有线网车站待接入，还有未来规划的100多个线网车站，怎么就100%了呢？

小明赶紧拿起电话呼唤起GBase的专家支持团队。GBase的专家支持团队收到信息，立刻派遣专家小安前往现场与运维人员小明进行对接。

数据库CPU狂飙100% GBASE专家来帮忙

小安在现场了解到：该项目生产使用的服务器，数据库绑定了64核CPU，总核数为128核，数据库监控软件GEM agent端也在这台服务器上，表空间总共分配了32TB，目前大约只使用了21TB左右，内存总754G，使用率在16%左右，磁盘为超融合磁盘，SSD作为缓存，磁盘写满会有一定比率的IO下降，但在可控范围内。

这么一看问题就出在CPU上了！小安立刻着手分析：

数据库占用64核，正常吃满应该是50%，到达90%可能是因为有GEM的agent端导致的CPU毛刺。于是关掉GEM的agent端进行以下验证。可以看到CPU毛刺消失了，CPU使用率很平滑，可见CPU毛刺并不影响数据库的性能。

接下来小安考虑是SQL运行导致的CPU占满，需要着手分析一下SQL的运行情况，于是输入“onstat -g ses 0”命令，每5分钟在主节点上执行生成一个文件，经过观察，在生成的文件里发现有大量重复的sql语句在执行。

小安猜测红色部分没有使用索引或者索引效率很低，于是查看其执行计划。

可以发现SQL走了索引，但是索引效率很低，怪不得这么慢呢，于是小安立刻给
加上了联合索引，把重复度低的字段靠前。

效果立竿见影，加上之后索引效率提升了1000倍。

经过几天观察，发现CPU利用率从50%降低到了20%。

小明给小安竖了一个大拇指，点了个赞，但同时小明也有疑问：其他SQL会不会也存在相同的问题呢，这是不是意味着CPU利用率还能继续下降？于是继续求助小安。

小安经过第一轮的分析，已经确认了问题所在，于是进行了第二轮调优，如法炮制，把所有CPU占用资源多的SQL都进行了分析，将没走索引或者走了索引但效率不高的SQL都进行了改造，经过SQL优化之后，CPU利用率从20%降低到了个位数。

至此，数据库性能问题被彻底解决。

在后续业务系统中，还发现某业务报表系统在改造前的系统用Oracle时需要半个小时出结果，更换为GBase 8s之后几分钟就出结果，客户大喜，对小安进行了点名表扬。

故障处理小课堂

Ø 数据库设计是一门学问，有时候不是数据库“不好用”，而是规划有问题，在理解业务和数据库特性的前提下合理对数据库库、表、索引等进行规划设计，才能最大程度激发数据库的真实性能。

Ø 从业务接入量来看，当前接入397个站点数据，以128核CPU为例，80%为瓶颈线，数据库需要接入397*8=3176个站点数据才能出现性能瓶颈，如果以64核CPU为例，未来规划的全线路接入，总站点总数不到800，64核CPU的使用率不到40%，如果全面优化，CPU使用率估计会在20%左右甚至更低，当然这需要应用程序方共同出力。

Ø 本次问题处理可以看出，GBase 8s V8.8 SSC共享存储集群能够支持非常庞大的业务量，并且数据库集群成本和运维成本更低。因此，我们在数据库选型要尽量避免“刻板印象”，往往能够满足业务需求的数据库产品与集群技术才是最好的选择。