这是一个创建于 401 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 · 2023-09-28 12:36:24 +08:00
用 Elixir 重写了业务逻辑, 跑的快快的
第 2 条附言 · 2023-09-28 12:36:56 +08:00
第 3 条附言 · 2023-09-28 12:44:08 +08:00
我搞不懂一个 "成熟的组件" 需要我小心翼翼的使用
第 4 条附言 · 2023-09-28 23:48:08 +08:00
使用时间长了之后产生慢 SQL #2415
https://github.com/xuxueli/xxl-job/issues/2415
https://github.com/xuxueli/xxl-job/issues/2415
 |
1
keepRun 2023-09-28 01:35:12 +08:00 via Android
你这属于没用好工具吧
|
 |
2
stinkytofu 2023-09-28 01:42:03 +08:00
我不信这个库本身有这样明显的问题, 检查一下你的代码吧
|
 |
3
securityCoding 2023-09-28 04:05:18 +08:00 via Android
在写日志吧
|
 |
4
Mogugugugu 2023-09-28 08:59:40 +08:00
所以问题是什么呢？
|
 |
5
dlmy 2023-09-28 09:04:24 +08:00
如果确定是 xxl-job 的问题，可以去提 issue ，别在这尬黑
|
 |
6
zzzb002 2023-09-28 09:05:42 +08:00
是不是有个异常日志一直报？那种很频繁的，可能会造成 IO 上去，网上解决方案很多
|
 |
7
yongjing 2023-09-28 09:15:30 +08:00
log 表数据量有多少？ 分页查询 COUNT 总条数，会导致扫全表， 记得及时清理~
|
 |
8
limyel 2023-09-28 09:19:15 +08:00
这种应用广泛的中间价，出问题了一般先考虑一下是不是自己的问题。
|
 |
10
xiaocaiji111 2023-09-28 09:20:08 +08:00
找到问题再黑，企业这个用的多的很，还是规模化的企业。就是 ui 界面之类丑了些。
|
 |
11
panzhc 2023-09-28 09:20:43 +08:00
xxljob 默认首页是运行报表，是查数据库的，如果运行时间比较久，日志表里数据量比较大，就会导致数据库 iops 高，而且是首页，任何人登录以后都会查一下。
解决办法要么清日志，要么改下登录后的默认首页。 |
 |
12
arischow 2023-09-28 09:34:32 +08:00
如果你真的想解决问题，请不要用这种反问。
|
 |
13
JinTianYi456 2023-09-28 09:36:19 +08:00
TRUNCATE xxl_job.xxl_job_log;
|
 |
14
lidashuang OP @stinkytofu 就是 xxl job 的慢 查询, 用 Elixir 重写了
@keepRun @dlmy 哪黑了? top 1 的慢查询都是 xxl job 的 https://cos.ap-beijing.myqcloud.com/dropshare-1252438752/pb-CXh3WYn7C3-g66UmVt6nLQ1pHw25Aguh2z9l3wvSH4.png |
|
15
lidashuang OP |
|
16
lidashuang OP @panzhc 管理后台没人查, 就是 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 1000 SELECT 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 |
|
17
lidashuang OP @yongjing 最多的是 xxl_job_info, 另外是 xxl_job_log
|
|
18
lidashuang OP @arischow 我已经解决了, 就是去掉 xxl job
|
 |
19
yanhuamiluan 2023-09-28 13:59:36 +08:00
吃了个烂苹果, 问为啥有人要吃苹果
|
 |
20
Masoud2023 2023-09-28 14:03:00 +08:00
有人用不代表这东西质量方面过关。
这东西本身工程质量就不太好，但是用着真的快糙猛，时间长了也就这样了。 |
 |
21
cp19890714 2023-09-28 14:19:02 +08:00  2
确实有这个问题。需要定期清理日志，我现在是用数据库运维工具自动清理。
你是懂起语言艺术的，6 个字，即骂了 xxljob ，也骂了用 xxljob 的人。 |
 |
22
zsdroid 2023-09-28 14:50:40 +08:00
提个 issue 比发牢骚更麻烦吗？
|
|
23
Mogugugugu 2023-09-28 14:59:23 +08:00
|
|
24
dlmy 2023-09-28 15:02:50 +08:00 1
一个是 JobScheduleHelper 类中的 scheduleThread 线程，会一直去扫 xxl_job_info 表，取出即将要执行的任务；
一个是 JobFailMonitorHelper 类中的 monitorThread 线程，会从数据库 xxl_job_log 表中查询执行失败并且报警状态码还未改变的定时任务，10s 执行一次； 这两个组件会一直扫描库表，当库表中数据量过大时，可能会出现这类问题，麻烦你去看看 xxl-job 的 issues ，去看看这个中间件的源码，不要出了问题就在这里鬼叫 |
|
25
dlmy 2023-09-28 15:09:18 +08:00
团队如果没人精读过源码，解决不了常见的问题，当初为什么要选用这个技术呢？
你发这个帖，起个这样的标题，是想实际解决问题还是想让我们帮忙一起喷这个中间件呢？ 啥都不懂，出了问题就会鬼叫，你有本事自己也写几个中间件出来，把生态建设起来呀，别躲在键盘后面尬黑好么 |
 |
26
zhongjun96 2023-09-28 15:24:54 +08:00
@lidashuang #17 xxl_job_info 这里是任务列表，任务怎么会比日志还多？
|
 |
27
burymme11 2023-09-28 16:19:34 +08:00
如果用 Elixir 重写后的业务逻辑出了问题，我想看到你怒喷 Elixir 的帖子。
|
 |
28
leeg810312 2023-09-28 16:34:11 +08:00
开源的东西不是收费产品，得自己运维，既然有很多人在用，说明主要特性符合需求，有些非关键特性可以自己开发补足或用其他方法解决。
|
 |
29
wbd31 2023-09-28 17:27:29 +08:00
|
|
30
lidashuang OP |
|
31
lidashuang OP @burymme11 java 微服务搞成单体, 机器配置降了很多, 延时好了很多, 之前 Java 服务一启动, 那 cpu 可壮观了
|
 |
32
statumer 2023-09-28 23:51:47 +08:00 via iPhone
提醒您啊，对象存储 cos bucket 地址暴露出来是很危险的，最好删掉了
|
|
33
lidashuang OP @statumer 感谢, 我专门拿来当图床的, 没啥大问题
|
|
34
lidashuang OP |
|
35
lidashuang OP @dlmy 我是不懂, 所以我不用了啊, 吐槽还不行?
|
|
36
dlmy 2023-09-29 09:43:53 +08:00
@lidashuang #34 既然你接盘了这套东西，至少得知道分布式任务调度框架会有调度中心跟执行器，然后会有一个分布式协调中心，这些基本的东西，你应该得知道呀。
当程序运行时，会启用哪些组件，这些组件里面包含了什么（比如 工作线程、工作线程池等）、分别干了什么（比如 扫表、调度、触发任务、通信）、哪些组件会占用服务器较多的资源（比如 间隔多久查一次表、sql 是怎样的），然后结合一些可观测性的指标，马上就能定位到源码了，这不就是程序员每天工作的日常吗？ 所以到底是你自己不够了解这套东西，还是这套东西本来就有问题呢？ 你好好拿出来说明，大家一起帮忙看下，不就能很快解决么，你直接张嘴就尬黑，这样谁会认真帮你去看问题？ |
|
37
lidashuang OP @dlmy 我自己已经解决了 才发的帖子, 我就是发泄情绪哈哈
|
 |
38
hzzhzzdogee 2023-09-29 13:39:18 +08:00
OP 这个图表是什么工具提供的呀
|
 |
39
cowcomic 2023-09-29 16:05:10 +08:00 1
在多个项目上用到了，主要原因就是不重复造轮子，我对于这类中间件的质量概念是存活时间+大家的使用量+更新频率+对应的业务场景+issue=品质，xxljob 从开始就还是比较信任的，没怎么做测试就直接使用。一直也的确没什么问题。跟他对应的比如 shardingsphere-proxy 和 debezium ，这两个都是比较早期就开始用，用的人也不多，业务也比较核心，所以做了大量测试才引入
至于日志的问题，当初在引入 xxljob 的时候就考虑到了，所以建设的时候就配套了清理机制，反映在架构设计相关文档和部署文档中，后续相关人交接也没出过什么问题 仅供参考 |
|
40
lidashuang OP @hzzhzzdogee aliyun 监控
|
Select Language