修改下内存配置，DolphinScheduler CPU 飙升问题秒解决
某公司在迁移从阿里云 DataWorks 到自建大数据平台过程中，遇到海豚调度器在定时任务触发时导致 CPU 负载激增甚至系统崩溃的问题。经过排查，发现并非任务数量过多引起，而是调度器配置不当。通过调整海豚调度器的线程数和 CPU 限制值，成功解决了 CPU 飙升问题，确保了任务的平稳运行。参考此案例，用户在调整线程数时需平衡机器负载和并发任务需求。
背景
公司准备将之前一直使用的阿里云 DataWorks 产品进行下线，然后建设自己的大数据平台，全部采用开源组件。由于成本方面的控制，刚开始，公司并拿不出很多的资金去买很多的服务器，直接一步到位，只能是先购买 4 台 ECS 服务器，然后先将所有的组件进行混布，之后随着任务的迁移，将 DataWorks 的资源慢慢的下掉一些，然后再把对应的成本放到自建的大数据平台上。
对于调度平台，我们也是直接选择了目前比较火的海豚调度器。
遇到的问题
其他同事将 DataWroks 上的离线任务迁移到海豚调度器上，改为 hive sql 实现。一段时间之后，海豚调度器上的任务已经有很多了，除了每天凌晨 2 点和 3 点的任务，每 5 分钟定时调度的任务也有很多。后来我们发现，每到 5 分钟定时触发的时候，我们的 ECS 机器的 CPU 负载就会从不到 5% 飙升到 100%，并且持续几秒钟。早上 2 点和 3 点的时候更严重，经常导致机器上其他组件角色停止运行，严重时，会直接导致机器底层操作系统奔溃，如下图所示：
排查过程
我们刚开始以为是每到 5 分钟，或者是凌晨 2 点定时调度很多任务的时候，由于瞬间调度器来的任务有很多，同时运行的任务太多，导致资源消耗突然增高。然后我们手动将所有的任务放到同一个任务组中，然后观察资源消耗情况。之后我们发现，资源的使用曲线上，确实是更平滑了一些，但是每到 5 分钟，和凌晨 2 点的时候，还是会飙升，问题依旧没有得到根本解决。
然后我们就下线了所有任务的定时调度，只上线了 hive sql 类型任务的 5 分钟定时调度。但是，每到 5 分钟调度的时候，CPU 使用率还是会飙升到 100%，这说明，并不是瞬间运行的任务过多造成的，因为此时被调度的任务并不是很多，而且相对修改之前，任务数量已经下降了很多了。
最后，我们只能去排查海豚调度器自身是否会占用很多资源了。
解决方案
通过查看海豚调度器的 master、worker 配置文件，我们发现，在他们的 application.yaml 文件中，有一些和线程数以及 CPU、内存相关的配置，master 下的 application.yaml 文件中相关配置如下：
worker 下的 application.yaml文件中相关配置如下：
master 下的 start.sh 文件有关 jvm 启动内存设置如下：
worker 下的 start.sh 文件有关 jvm 启动内存设置如下：
如果自己的机器内存不是很多，也可以调整 start.sh 中有关 JVM 内存设置。
我们主要调整了 master 和 worker 下的 application.yaml 文件中有关线程数量和 cpu 限制值，线程数量全部调整为 3，CPU 限制，从 -1 调整为 4，我们机器的 CPU 核数均为 8，具体调整的数字，可以按照自己机器的配置来决定，也可以进行多次尝试。
之后我们再次观察机器的 CPU 使用率，发现每到 5 分钟调度时候，十分平稳，而且在凌晨 2 点和 3 点的时候，即使瞬间要调度器很多任务，也不会造成 CPU 飙升的情况，而且任务也在平稳运行，如下图所示：
不过需要注意的是：
当把线程数调整小之后，可以被同时调度器来的任务数量将会变小，比如我上面调整每个 worker 的线程数为 3，一共 5 个 worker 节点，则整个海豚调度器并发执行的任务数量最大为 15，所以具体的线程数量，需要根据自己机器的负载，以及需要被同时调度的任务数量来共同调度，找到一个合理的值，既能够保证机器的负载不会突然飙升，也能够保证被定时调度的任务能够在合理的时间内执行完成。
转载自第一片心意
原文链接：https://blog.csdn.net/u012443641/article/details/129777498
一家开源原生的DataOps商业公司。 2022-03-18 加入
致力于打造下一代开源原生的DataOps 平台，助力企业在大数据和云时代，智能化地完成多数据源、多云及信创环境的数据集成、调度开发和治理，以提高企业解决数据问题的效率，提升企业分析洞察能力和决策能力。
评论