你要偷偷学会排查线上CPU飙高的问题

上面的堆栈信息，可以看出，占用CPU资源的线程主要是卡在JDBC底层的TCP套接字读取上。连续执行了很多次，发现很多线程都是卡在这个地方。

通过分析调用链，发现这个地方是我代码中有数据库的insert，并且使用TDDL（阿里内部的分布式数据库中间件）来创建sequence，在sequence的创建过程中需要和数据库有交互。

但是，基于对TDDL的了解，TDDL每次从数据库中查询sequence序列的时候，默认会取出1000条，缓存在本地，只有用完之后才会再从数据库获取下一个1000条序列。

按理说我们的压测QPS只有300左右，不应该这么频繁的何数据库交互才对。但是，经过多次使用Arthas的查看，发现大部分CPU都耗尽在这里。

于是开始排查代码问题。最终发现了一个很傻的问题，那就是我们的sequence创建和使用有问题：因为，我们每次insert语句都重新build了一个新的sequence，这就导致本地缓存就被丢掉了，所以每次都会去数据库中重新拉取1000条，但是只是用了一条，下一次就又重新取了1000条，周而复始。

于是，调整了代码，把Sequence实例的生成改为在应用启动时初始化一次。这样后面在获取sequence的时候，不会每次都和数据库交互，而是先查本地缓存，本地缓存的耗尽了才会再和数据库交互，获取新的sequence。预发布默认开启了TDDL的采集（官方文档中描述为预发布默认不开启TDDL采集，但是实际上会采集）。

这个工具在打印日志过程中会进行脱敏，脱敏框架会调用Google的re2j进行正则表达式的匹配。

因为我的操作中TDDL操作比较多，默认采集大量TDDL日志并且进行脱敏处理，确实比较耗费CPU。

所以，通过在预发布中关闭DP对TDDL的采集，即可解决该问题。

总结与思考

本文总结了一次线上CPU飙高的问题排查过程，其实问题都不难，并且还挺傻的，但是这个排查过程是值得大家学习的。

其实在之前自己排查过很多次CPU飙高的问题，这次也是按照老方法进行排查，但是刚开始并没有发现太大的问题，只是以为是流量升高导致数据库操作变多的正常现象。

期间又多方查证（通过Arthas查看sequence的获取内容、通过数据库查看最近插入的数据的主键ID等）才发现是TDDL的Sequence的初始化机制有问题。

在解决了这个问题之后，以为彻底解决问题，结果又遇到了DP采集TDD

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!