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_count | znodes的数量 |
实际16C64G跑8个任务就OOM了
有超过4个大任务,内存使用直接60多G用满,直到机器OOM,运维给出机器内存超过100%的告警
最后完成上线
不同的version可以跑不一样的任务,策略完全掌握在自己手中
动态调整
总结
以上是关于druid.io 自定义实时任务调度策略的主要内容,如果未能解决你的问题,请参考以下文章
Linux(内核剖析):11---进程调度之实时调度策略(SCHED_FIFOSCHED_RRMAX_RT_PRIO实时优先级)