把 xxl job 去掉, 数据 io 立马正常了
cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-d3nSG4K4GL-ENRkABrCGyVHa20BISGvbsrOCRiOL6w.png

用 Elixir 重写了业务逻辑, 跑的快快的

用这个东西还要我定期去清理 cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-CXh3WYn7C3-g66UmVt6nLQ1pHw25Aguh2z9l3wvSH4.png

我搞不懂一个 "成熟的组件" 需要我小心翼翼的使用

使用时间长了之后产生慢 SQL ＃2415 github.com/xuxueli/xxl-job/issues/2415

你这属于没用好工具吧

我不信这个库本身有这样明显的问题, 检查一下你的代码吧

在写日志吧

所以问题是什么呢？

如果确定是 xxl-job 的问题，可以去提 issue ，别在这尬黑

是不是有个异常日志一直报？那种很频繁的，可能会造成 IO 上去，网上解决方案很多

log 表数据量有多少？ 分页查询 COUNT 总条数，会导致扫全表， 记得及时清理~

这种应用广泛的中间价，出问题了一般先考虑一下是不是自己的问题。

中间价 -> 中间件

找到问题再黑，企业这个用的多的很，还是规模化的企业。就是 ui 界面之类丑了些。

xxljob 默认首页是运行报表，是查数据库的，如果运行时间比较久，日志表里数据量比较大，就会导致数据库 iops 高，而且是首页，任何人登录以后都会查一下。解决办法要么清日志，要么改下登录后的默认首页。

如果你真的想解决问题，请不要用这种反问。

TRUNCATE xxl_job.xxl_job_log;

就是 xxl job 的慢 查询, 用 Elixir 重写了 哪黑了?top 1 的慢查询都是 xxl job 的 cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-CXh3WYn7C3-g66UmVt6nLQ1pHw25Aguh2z9l3wvSH4.png

我清理过最终还是去掉这个组件, 用别的语言重写了, Java 我不太懂

管理后台没人查, 就是 xxl job 自己跑的逻辑查比如SELECT id FROM xxl_job_log WHERE !( (trigger_code in (0, 200) and handle_code = 0) OR (handle_code = 200) ) AND alarm_status = 0 ORDER BY id ASC LIMIT 1000SELECT t.id, t.job_group, t.job_cron, t.job_desc, t.add_time, t.update_time, t.author, t.alarm_email, t.executor_route_strategy, t.executor_handler, t.executor_param, t.executor_block_strategy, t.executor_timeout, t.executor_fail_retry_count, t.glue_type, t.glue_source, t.glue_remark, t.glue_updatetime, t.child_jobid, t.trigger_status, t.trigger_last_time, t.trigger_next_time FROM xxl_job_info AS t WHERE t.trigger_status = 1 and t.trigger_next_time <= 1695571207054 ORDER BY id ASC LIMIT 6000

最多的是 xxl_job_info, 另外是 xxl_job_log

我已经解决了, 就是去掉 xxl job

吃了个烂苹果, 问为啥有人要吃苹果

有人用不代表这东西质量方面过关。这东西本身工程质量就不太好，但是用着真的快糙猛，时间长了也就这样了。

确实有这个问题。需要定期清理日志，我现在是用数据库运维工具自动清理。你是懂起语言艺术的，6 个字，即骂了 xxljob ，也骂了用 xxljob 的人。

提个 issue 比发牢骚更麻烦吗？

www.xuxueli.com/xxl-job/＃5.22%20%E6%97%A5%E5%BF%97%E8%87%AA%E5%8A%A8%E6%B8%85%E7%90%86文档有说日志自动清理，不知道有人配置试过么

一个是 JobScheduleHelper 类中的 scheduleThread 线程，会一直去扫 xxl_job_info 表，取出即将要执行的任务；一个是 JobFailMonitorHelper 类中的 monitorThread 线程，会从数据库 xxl_job_log 表中查询执行失败并且报警状态码还未改变的定时任务，10s 执行一次；这两个组件会一直扫描库表，当库表中数据量过大时，可能会出现这类问题，麻烦你去看看 xxl-job 的 issues ，去看看这个中间件的源码，不要出了问题就在这里鬼叫

团队如果没人精读过源码，解决不了常见的问题，当初为什么要选用这个技术呢？你发这个帖，起个这样的标题，是想实际解决问题还是想让我们帮忙一起喷这个中间件呢？啥都不懂，出了问题就会鬼叫，你有本事自己也写几个中间件出来，把生态建设起来呀，别躲在键盘后面尬黑好么

＃17 xxl_job_info 这里是任务列表，任务怎么会比日志还多？

如果用 Elixir 重写后的业务逻辑出了问题，我想看到你怒喷 Elixir 的帖子。

开源的东西不是收费产品，得自己运维，既然有很多人在用，说明主要特性符合需求，有些非关键特性可以自己开发补足或用其他方法解决。

github.com/xuxueli/xxl-job/issues/24152021 年的 issue 居然还是 open 状态。。我倒是支持 op 的看法。

你是懂起语言艺术的，6 个字，即骂了 xxljob ，也骂了用 xxljob 的人。 引入这个的人给我带来了太多的痛苦

java 微服务搞成单体, 机器配置降了很多, 延时好了很多, 之前 Java 服务一启动, 那 cpu 可壮观了

提醒您啊，对象存储 cos bucket 地址暴露出来是很危险的，最好删掉了

感谢, 我专门拿来当图床的, 没啥大问题

团队如果没人精读过源码，解决不了常见的问题，当初为什么要选用这个技术呢？我不认识之前引入这些的人, 我帮别人优化, 如果这个东西需要看源码才能用好的话? 我真的不想用, 很累

我是不懂, 所以我不用了啊, 吐槽还不行?

＃34 既然你接盘了这套东西，至少得知道分布式任务调度框架会有调度中心跟执行器，然后会有一个分布式协调中心，这些基本的东西，你应该得知道呀。当程序运行时，会启用哪些组件，这些组件里面包含了什么（比如 工作线程、工作线程池等）、分别干了什么（比如 扫表、调度、触发任务、通信）、哪些组件会占用服务器较多的资源（比如 间隔多久查一次表、sql 是怎样的），然后结合一些可观测性的指标，马上就能定位到源码了，这不就是程序员每天工作的日常吗？所以到底是你自己不够了解这套东西，还是这套东西本来就有问题呢？你好好拿出来说明，大家一起帮忙看下，不就能很快解决么，你直接张嘴就尬黑，这样谁会认真帮你去看问题？

我自己已经解决了 才发的帖子, 我就是发泄情绪哈哈

OP 这个图表是什么工具提供的呀