记一次CPU百分百的问题

服务拆分迁移，但是拆分后的子服务，会有一台机器CPU 飙100%，持续一下就没了。

背景

一个定时任务服务，由于定时任务属于边缘业务，各业务线发展拆分时，一直没有动这个服务。 最近这个服务改动太过频繁，太多业务在一个服务上，今天这个上线，明天那个上线。

那就拆吧，各个业务线自己拎走自己的业务。

其中一个2B 业务线的定时任务，在拆分后，会有一台服务器CPU 飙100%。

问题表象

一个凌晨的定时任务，会对所有企业客户做一次一天内的数据统计。

然后这个任务在执行时，就会有 CPU 飙100%。

问题排查

一） 查监控

查了下监控，在 CPU 飙高时，是 java 线程飙起来的。

此时没有 YGC 和 FGC。没有系统异常。

排队服务问题

二）看代码

任务流程比较长，长期打补丁的操作，使任务的性能比较低。

都是一些比较频繁的计算动作。典型的 CPU 密集型服务。

更要命的是，任务中有多处递归调用。还有几处的嵌套递归调用。

这玩意，CPU 不高才怪。

三）为啥没拆之前没会飙高呢？

没拆之前，各业务线在同一上服务上，服务扩容最后有10台服务器。拆分后这个业务上只拿到2台服务器。

线上数百家的企业客户，由10台变2台。处理是有点费劲。

问题一下子明了了。

根本问题

一）代码写的不好 ，很需要优化。但逻辑又臭又长，一时没人下得了手。

二）由10台服务器一下子降到2台。任务略有压力

解决

好在是定时任务，没有时效要求。

当前服务器 CPU 是 4 核 4 线程。任务线程池的线程数降到2 。

2个线程打爆了也只占50% 。

任务时间由原来的20分钟，延长到了2小时。

根本解决

还得从代码上根本解决，任务拆分，结构化计算逻辑。

去掉递归调用。

服务器压力还是有的 。后面还抗不往就得加机器了。

总结

历史包袱啊。。。 唉！只能说每个人尽量自觉些，写代码用点心。