当前位置： 首页互联网正文 本文介绍: xxl–job，日志过大，故障 传送门 分布式定时任务系列1：XXL-job安装 分布式定时任务系列2：XXL-job使用 分布式定时任务系列3：任务执行引擎设计 分布式定时任务系列4：任务执行引擎设计续 分布式定时任务系列5：XXL-job中blockingQueue的应用 Java并发编程实战1：java中的阻塞队列 问题出现 前几天上班的时候，收到运维的告警通知，安装XXL-job的服务器CPU飙高告警，让看一下。 查了下xxl–job–admin的日志文件，目录在logback.xml： 发现在告警时间点之前报了一个db事物超时的错误。 通过讯问得知，有人手动清理过任务，即将无效的任务手动删除了：在xxl–job控制台创建了几个任务，后来业务变更，把代码里面的任务删除了，但是控制台任务没有删除，所以做任务清理。以前面的例子来进行说明 场景说明 开发第一个jobHandler @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方法本身也平平无奇： <delete id="delete" > delete from xxl_job_log WHERE job_id = #{jobId} </delete> 那么到底是为什么这行sql会报错呢？ 原因说穿了也很简单，因为这个任务对应的任务数据量太大了： xxl_job_log表，在经过系统接近半年运行，这张表已经存储超过了1kw+数据量，这对mysql来说单表的数据量算比较大了，甚至会造成从界面查询调度日志都成问题 单个任务删除时，在删除任务对应的调度日志时，数据量也是10w+（甚至可能更多，取决于配置的触发频率），执行这个sql的时候，对db来说不仅IO消耗大，且成了一个长事物，久久不能结束最后事物超时+CPU飙高 问题解决 对于调试日志太大的问题，官网已经给出了解决方案 手动清理 可以通过看源码，看出它是根据界面选择的清理策略，发起一个http同步请求，做循环删除，也是比较粗暴： 自动清理 原理就是启动异步线程，执行删除，具体可以看下源码。 原文地址:https://blog.csdn.net/weigeshikebi/article/details/134603531 本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。 如若转载，请注明出处：http://www.7code.cn/show_13653.html 如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！ 主题授权提示：请在后台主题设置-主题授权-激活主题的正版授权，授权购买：RiTheme官网显示所有内容声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。jobxxl分布式 代码007普通 打赏 收藏 海报 链接
