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也是配置已知的，那么只要合理的分配，确保sum{requireCapacity} <= 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_count	znodes的数量

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

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

最后完成上线

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

动态调整

总结