海豚调度器自身资源消耗控制_海豚 调度

1. 背景

公司最近准备将之前一直使用的阿里云 DataWorks 产品进行下线，然后建设自己的大数据平台，全部采用开源组件。由于成本方面的控制，刚开始，公司并拿不出很多的资金去买很多的服务器，直接一步到位，只能是先购买 4 台 ECS 服务器，然后先将所有的组件进行混布，之后随着任务的迁移，将 DataWorks 的资源慢慢的下掉一些，然后再把对应的成本放到自建的大数据平台上。

对于调度平台，我们也是直接选择了目前比较火的海豚调度器，当时是直接搭建的最新版，后来也升级到了现在的最新版：3.1.4。

2. 遇到的问题

其他同事最近一直在将 DataWroks 上的离线任务迁移到海豚调度器上，改为 hive sql 实现。一段时间之后，海豚调度器上的任务已经有很多了，除了每天凌晨 2 点和 3 点的任务，每 5 分钟定时调度的任务也有很多。后来我们发现，每到 5 分钟定时触发的时候，我们的 ECS 机器的 CPU 负载就会从不到 5% 飙升到 100%，并且持续几秒钟。早上 2 点和 3 点的时候更严重，经常导致机器上其他组件角色停止运行，严重时，会直接导致机器底层操作系统奔溃，如下图所示：

3. 排查过程

我们刚开始以为是每到 5 分钟，或者是凌晨 2 点定时调度很多任务的时候，由于瞬间调度器来的任务有很多，同时运行的任务太多，导致资源消耗突然增高。然后我们手动将所有的任务放到同一个任务组中，然后观察资源消耗情况。之后我们发现，资源的使用曲线上，确实是更平滑了一些，但是每到 5 分钟，和凌晨 2 点的时候，还是会飙升，问题依旧没有得到根本解决。

然后我们就下线了所有任务的定时调度，只上线了 hive sql 类型任务的 5 分钟定时调度。但是，每到 5 分钟调度的时候，CPU 使用率还是会飙升到 100%，这说明，并不是瞬间运行的任务过多造成的，因为此时被调度的任务并不是很多，而且相对修改之前，任务数量已经下降了很多了。

最后，我们只能去排查海豚调度器自身是否会占用很多资源了。

4. 解决方案

通过查看海豚调度器的 master、worker 配置文件，我们发现，在他们的 application.yaml 文件中，有一些和线程数以及 CPU、内存相关的配置，master 下的 application.yaml 文件中相关配置如下：

# 线程数相关配置
fetch-command-num: 10
# master prepare execute thread number to limit handle commands in parallel
pre-exec-threads: 10
# master execute thread number to limit process instances in parallel
exec-threads: 100
# master dispatch task number per batch, if all the tasks dispatch failed in a batch, will sleep 1s.
dispatch-task-number: 3

# CPU、内存相关配置
# master max cpuload avg, only higher than the system cpu load average, master server can schedule. default value -1: the number of cpu cores * 2
# 如果 cpu load 值大于下面设置的值，则该 worker 角色会停止服务，直到 cpu load 值小于下面设置的值，默认不限制
max-cpu-load-avg: -1
# master reserved memory, only lower than system available memory, master server can schedule. default value 0.3, the unit is G
# 如果剩余的内存小于下面设置的值（单位：G），则该 worker 角色会停止服务，直到剩余的内存值大于下面设置的值，默认为 0.3G
reserved-memory: 0.3
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

worker 下的 application.yaml 文件中相关配置如下：

# 线程数相关配置
# worker execute thread number to limit task instances in parallel
exec-threads: 100

# CPU、内存相关配置
# worker max cpuload avg, only higher than the system cpu load average, worker server can be dispatched tasks. default value -1: the number of cpu cores * 2
# 如果 cpu load 值大于下面设置的值，则该 worker 角色会停止服务，直到 cpu load 值小于下面设置的值，默认不限制
max-cpu-load-avg: -1
# worker reserved memory, only lower than system available memory, worker server can be dispatched tasks. default value 0.3, the unit is G
# 如果剩余的内存小于下面设置的值（单位：G），则该 worker 角色会停止服务，直到剩余的内存值大于下面设置的值，默认为 0.3G
reserved-memory: 0.3
1
2
3
4
5
6
7
8
9
10
11

master 下的 start.sh 文件有关 jvm 启动内存设置如下：

JAVA_OPTS=${JAVA_OPTS:-"-server -Duser.timezone=${SPRING_JACKSON_TIME_ZONE} -Xms4g -Xmx4g -Xmn2g -XX:+PrintGCDetails -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=dump.hprof"}
1

worker 下的 start.sh 文件有关 jvm 启动内存设置如下：

JAVA_OPTS=${JAVA_OPTS:-"-server -Duser.timezone=${SPRING_JACKSON_TIME_ZONE} -Xms4g -Xmx4g -Xmn2g -XX:+PrintGCDetails -Xloggc:gc.log -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=dump.hprof"}
1

如果自己的机器内存不是很多，也可以调整 start.sh 中有关 JVM 内存设置。

我们主要调整了 master 和 worker 下的 application.yaml 文件中有关线程数量和 cpu 限制值，线程数量全部调整为 3，CPU 限制，从 -1 调整为 4，我们机器的 CPU 核数均为 8，具体调整的数字，可以按照自己机器的配置来决定，也可以进行多次尝试。

之后我们再次观察机器的 CPU 使用率，发现每到 5 分钟调度时候，十分平稳，而且在凌晨 2 点和 3 点的时候，即使瞬间要调度器很多任务，也不会造成 CPU 飙升的情况，而且任务也在平稳运行，如下图所示：

不过需要注意的是：

当把线程数调整小之后，可以被同时调度器来的任务数量将会变小，比如我上面调整每个 worker 的线程数为 3，一共 5 个 worker 节点，则整个海豚调度器并发执行的任务数量最大为 15，所以具体的线程数量，需要根据自己机器的负载，以及需要被同时调度的任务数量来共同调度，找到一个合理的值，既能够保证机器的负载不会突然飙升，也能够保证被定时调度的任务能够在合理的时间内执行完成。