EasyScheduler线上任务调度延迟1小时问题排查

1、背景

早上，暴躁君W来了条信息:"小时计算任务延迟一小时执行,致使应该6点启动的计算3点数据的任务到7点才被提交执行，而计算4点数据的任务跑了两次,帮忙排查下这个问题。"数据库

2、那么问题来了

从上述架构图咱们知道，MasterServer进行任务的生成，放至Task Queue中，WorkerServer从Task Queue中消费任务进行执行。其次，EasyScheduler有一配置特性，若是当前结点CPU或者内存达到了80%以上，则不会进行新的任务的调度和执行。bash

综合上述二者，大概猜想到了是master结点CPU负载太高致使的.定位步骤以下:markdown

经过公司的机器监控平台of-dashboard查看机器的CPU、内存最近一天使用状况

发现早上5点半开始到7点之间CPU负载呈现以80%为中心的正态分布，推断当时的确是触发了master结点的保护机制架构

查看master结点escheduler-master-xxx.log，观察早上06:00~07:00这段时间的日志

发现6点到7点这段时间一直处于80%高负载状态，持续打印 [WARN] 2019-10-22 06:01:41.344 cn.escheduler.common.utils.OSUtils:[290] - load or availablePhysicalMemorySize(G) is too high, it's availablePhysicalMemorySize(G):200.01,loadAvg:23.3 信息，彻底确认是由于高负载致使。优化

可是高负载缘由是什么呢？实际上是由于咱们混部了一些移动端采集任务在master结点上致使的（本意是处于充分利用机器）spa

从escheduler数据库中查询今日任务完成时间为6:00到7:18之间的任务实例信息

得出有三项数据计算任务均为高负载，且耗时跨度均为2~3小时，提取出该三项任务所属项目以及工做流定义信息，反馈给暴躁君，并让其进行任务优化或者时间段分摊负载以保证小时计算任务正常执行。日志

3、总结

问题定位都是有套路和步骤的，制定好troubleshooting的步骤，循序渐进能够事半功倍code
EasyScheduler的自我保护机制是可配置的，只需在install.sh配置文件中配置以下两个参数便可orm

# master最大cpu平均负载,用来判断master是否还有执行能力
masterMaxCpuLoadAvg="10"

# master预留内存,用来判断master是否还有执行能力
masterReservedMemory="1"
复制代码

你了解了EasyScheduler的套路了吗？