定时任务框架太多了,选个简单高可用的以为就安心用就完了,结果哈,最先发觉这个问题是今年的12月31日,我以为是我们的业务有bug了,当日提了问题linux游戏,发觉只有我们的没执行,就不自信了,不了了之了,近来又发生了。
那总的给个诱因吧,此次连带的是其他小分队的也没有执行,是2月26日
这么晚上运维给出了诱因。
缘由如下:
1.运维人员发觉xxx机器上(数据库c盘/home超过90%)百度网盘LINUX,步入数据库中查看到数据库xxljob库中,发觉XXL_JOB_QRTZ_TRIGGER_LOG约有16.5GB(王德发~)的数据,可以表中部分时间点数据,没有降低c盘使用空间。
该表解释是调度日志表:用于保存XXL-JOB任务调度的历史信息,如调度结果、执行结果、调度入参、调度机器和执行器等等;
2.操作命令:如下句子,执行后约20min,发觉c盘空间没有增长。
表:XXL_JOB_QRTZ_TRIGGER_LOG约有16.5GB
执行过程中
DELETE FROM XXL_JOB_QRTZ_TRIGGER_LOG WHERE trigger_time >= '2021-12-17 00:18:59' AND trigger_time <= '2021-12-18 23:59:20';
复制
操作可能造成数据库死锁或则CPU夯住了linux 计划任务没执行,造成0时执行的任务,没有执行成功。
解决方案:
目前生产环境xxljob-amdin数据库服务器(xxx)c盘总大小:27G已使用:9.7GB剩余约:17GB,须要合理评估一下数据下降量,数据库c盘容量大小进行扩容。
业务定时任务高峰期都集中夜晚,建议任务调度服务中的XXL_JOB_QRTZ_TRIGGER_LOG这张表保留近来一周的日志量,在业务低峰期每晚早晨:9:00定时执行脚本。
我默默的看了眼我生产数据库的最大表,4个G是2000万左右,16-17G也就是我的4倍,那而且将近一个亿啊,这说明哪些?他没按着业务中心去分表啊,把所有数据全置于一个表Allin了?别说你时间数组没建索引linux 计划任务没执行,就是建了索引看来三天日志量也不小啊,这一下就可能造成锁表?首先咱也是读过官方文档的,它不是支持动态分片的么,这删掉时间定为每晚9点,那这些每5分钟执行一次的任务是不是还得凉凉?