信贷项目实际案例
人脸重构
越南 timer 定时器, 延迟时间太长, 产品反馈现在影响较大, 暂定方案, 重启服务 ( 只能暂时缓解 ), 问过阿城, 上次 timer 启动时间是 1月23 号, 就是说重启只能缓解大概 半个月 左右 tips: 重启会导致任务丢失, 积压的任务会直接消失
现在明确是什么占用资源，挤压了么？
回复 诚悦: 报表 sql 执行时间过长, Quartz 提交任务到线程池, 但是线程数不够, 导致整个任务执行都顺延了, 时间越长, 积压会越多. 根因还是 sql 问题
回复 诚悦: @伯爵 现在明确是什么占用资源，挤压了么？ @诚悦 或者增加线程池的核心线程数, 现在的线程数是 CPU 核心数, 因为大量的等待行为是 IO , 这个数值可以增加
@伯爵 1. 短期改造的可以分配俩线程池不？ 报表的是不是需要容错下，比如已经排队到很久了，是不是应该放弃了？ 有可能逐步切换到xxljob了不，现在贷后已经全部接入了，贷前GG也在用了。
主要的耗时大户就这几个 次数多，平均执行时间长
@诚悦 后续可以出方案进行具体改造, 暂时比较安全快捷的方法是, 线程池核心线程扩容, 重启服务, 这样改动小, 可以免测, 防止节前出现问题
你们整体出一个吧，我感觉这个待办不能老忘记哈，上次发现后，以为解决了，其实还是有问题的，也是没加监控告警
等待任务数超过核心线程, 表明有积压风险, 超过 3 倍, 可能就会一直挤压, 产生任务顺延的问题了
@卡卡罗特 @诚悦 15 天时间执行了 30000+ 的任务, 平均每天任务数在 2000+, 后续可能还要梳理下定时任务信息, 是否真的有这么多的任务需要被执行
监控告警我一会儿增加 任务调度的治理，伯爵你和卡卡聊下呗，牵头治理下，应该是需要有点规划和方案的