分布式定时任务系列6：XXL-job触发日志过大引发的CPU告警

传送门

问题出现

前几天上班的时候，收到运维的告警通知，安装XXL-job的服务器CPU飙高告警，让看一下。

查了下xxl-job-admin的日志文件，目录在logback.xml：

发现在告警时间点之前报了一个db事物超时的错误。

通过讯问得知，有人手动清理过任务，即将无效的 任务手动删除了：在xxl-job控制台创建了几个任务，后来业务变更，把代码里面的任务删除了，但是控制台任务没有删除，所以做任务清理。以前面的例子来进行说明

场景说明

开发第一个jobHandler

java 复制代码

@Component
public class JobHandler {
 
    @XxlJob("first_job")
    public void firstJob() {
        System.out.println("========================= first job========================= ");
    }
}

若以上配置成功，则可以在控制台看到注册的客户端机器

新建任务

测试任务

经过以上设置，在平台手动触发一次任务，并且可以查看执行日志

删除代码中的任务

执行一段时间后，代码中删除first_job，但是控制台任务不删除，执行一段时间后现删除。

但是这个正常的变更操作为什么会引起db出错呢？因为很有可能由于业务变动，先将代码中对应的任务删除的，而后再来清理XXL-job控制台的任务。

问题重现

要解决这个问题，首先还是要定位到原因。

结合报错日志，翻看了一下源码，发现从XXL-job控制台删除任务的逻辑：

界面删除选中的任务，发起URL请求：xxl-job-admin/jobinfo/remove
后端接口，开始同步处理，代码如下
跟踪代码，会发现问题代码出在清理任务对应的触发日志那个步骤

而这个Dao方法本身也平平无奇：

XML 复制代码

	<delete id="delete" >
		delete from xxl_job_log
		WHERE job_id = #{jobId}
	</delete>

那么到底是为什么这行sql会报错呢？

原因说穿了也很简单，因为这个任务对应的任务数据量太大了：

xxl_job_log表，在经过系统接近半年运行，这张表已经存储超过了1kw+数据量，这对mysql来说单表的数据量算比较大了，甚至会造成从界面查询调度日志都成问题
单个任务删除时，在删除任务对应的调度日志时，数据量也是10w+（甚至可能更多，取决于配置的触发频率），执行这个sql的时候，对db来说不仅IO消耗大，且成了一个长事物，久久不能结束最后事物超时+CPU飙高