druid.io 自定义实时任务调度策略

Posted master-dragon

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了druid.io 自定义实时任务调度策略相关的知识,希望对你有一定的参考价值。

接上一篇《druid.io 实时和离线任务使用的MiddleManager分离【工作总结】》

主要是实时任务调度问题,其实网上也已经有博文或者类似文章思路是可以参考的;调度总是可以考虑很多因素的,这可以是专门的一块知识,比如hadoop yarn就是一个很好的参考,快手对druid.io任务改进似乎就采用了这种方式;但是我这里还是能力有限,没有用yarn,还是总结下实际的项目调整方案和实践流程。总之对比之前有改进就可以认为是个优秀的事情,但是不应该满足于此。

留个 todo

目录

背景 & 考虑点

实时任务的消耗

  • 堆内存:peon进程
  • 堆外内存: 查询 & 数据聚合 & jvm 元空间等

要想充分的利用资源,显然每一个实时任务的预估消耗要明确,显然这不太好非常准确,但可以有一个相对的值,考虑到任务总是有大有小的,所以对于配置应该是分层级的

eg:

-Xmx1g  -XX:MaxDirectMemorySize=2g 再预留0.5g堆外内存
-Xmx2g  -XX:MaxDirectMemorySize=2g 再预留0.5g堆外内存
-Xmx3g  -XX:MaxDirectMemorySize=2g 再预留1g堆外内存
...
-Xmx6g  -XX:MaxDirectMemorySize=2g 再预留3g堆外内存

或者换个思路,每个任务消耗内存多少是已知的 即每个任务的requireCapacity是已知的,那么每台middleManager的capacity也是配置已知的,那么只要合理的分配,确保sumrequireCapacity <= capacity就够了,充分的压榨middleManager的资源就好了,达到充分利用的目的。

预期效果&数据证明

实际上线测试

实际的其中之一的测试结果,对一个16C 64G的机器
可以配置capacity = 61440, 对于小任务设置其requireCapacity = 4608, 那么将能同时跑13个任务,且这时内存使用率能达到65%-70%(负载并不是很高,可忽略);显然还可以进一步提高使用

任务分配慢的问题?

zk相关指标在分配任务的10分钟内明显变化(分配任务是需要zk上创建节点的,节点内容大小主要与任务的task.json相关)

  • zk_znode_count: 315k—>320k 分配任务阶段一路升高
  • zk_outstanding_requests: 400.000 曲线图急剧变化,突刺特别多,最高快将近600了
  • zk_packets_received: 5k,10k,20k,图像突刺特别多 平时基本0

附:zk各指标含义

zk指标含义
zk_outstanding_requests排队请求的数量,当ZooKeeper超过了它的处理能力时,这个值会增大,建议设置报警阀值为10
zk_packets_received接收到客户端请求的包数量
zk_znode_countznodes的数量

实际16C64G跑8个任务就OOM了

有超过4个大任务,内存使用直接60多G用满,直到机器OOM,运维给出机器内存超过100%的告警

最后完成上线

不同的version可以跑不一样的任务,策略完全掌握在自己手中

动态调整

总结

以上是关于druid.io 自定义实时任务调度策略的主要内容,如果未能解决你的问题,请参考以下文章

在linux中如何根据nice值设置任务时间片

Linux的实时任务调度

Linux 线程调度与优先级

Linux(内核剖析):11---进程调度之实时调度策略(SCHED_FIFOSCHED_RRMAX_RT_PRIO实时优先级)

linux 进程优先级 之设置实时进程 (另一种方式是设置nice值)

Linux(内核剖析):07---进程调度总体概述(多任务系统策略时间片)