一、背景
早上，暴躁君 W 来了条信息:” 小时计算任务延迟一小时执行, 导致应该 6 点启动的计算 3 点数据的任务到 7 点才被提交执行，而计算 4 点数据的任务跑了两次, 帮忙排查下这个问题。”
二、那么问题来了
从上述架构图我们知道，MasterServer 进行任务的生成，放至 Task Queue 中，WorkerServer 从 Task Queue 中消费任务进行执行。
其次，EasyScheduler 有一配置特性，如果当前结点 CPU 或者内存达到了 80% 以上，则不会进行新的任务的调度和执行。
综合上述两者，大概猜测到了是 master 结点 CPU 负载过高导致的. 定位步骤如下:
- 通过公司的机器监控平台
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 结点上导致的（本意是处于充分利用机器）
- 从 escheduler 数据库中查询今日任务完成时间为 6:00 到 7:18 之间的任务实例信息
得出有三项数据计算任务均为高负载，且耗时跨度均为 2~3 小时，提取出该三项任务所属项目以及工作流定义信息，反馈给暴躁君，并让其进行任务优化或者时间段分摊负载以保证小时计算任务正常执行。
三、总结
- 问题定位都是有套路和步骤的，制定好 troubleshooting 的步骤，按部就班可以事半功倍
- EasyScheduler 的自我保护机制是可配置的，只需在
install.sh配置文件中配置如下两个参数即可
# master 最大 cpu 平均负载, 用来判断 master 是否还有执行能力
masterMaxCpuLoadAvg="10"
# master 预留内存, 用来判断 master 是否还有执行能力
masterReservedMemory="1"- 你了解了 EasyScheduler 的套路了吗？