背景
Flink 中 Network Buffer 相关配置对用户来说比较复杂，用户很难去配置一个合理的值，使用过程中主要以下两方面问题
- NetworkBuffer 不够导致的作业启动失败
- 大部分作业 NetworkBuffer 浪费严重
期望寻找一种合理的方式来解决 NetworkBuffer 不足导致的作业启动失败的问题，减少 NetworkBuffer 内存浪费，提升内存资源利用率
现状
目前的配置方式
- 通过参数配置每个 TM 上 network buffer 比例&大小
- TM 中 NetworkBufferPool 对 Network Buffer 进行统一管理，TM 启动时就会分配所有内存
备注：NetworkBuffer 支持堆内/堆外(默认)内存两种方式
NetworfBuffer 分配规则
- NetworkBufferPool 对 TM 上 NetworkBuffer Quota 作统一管理，每次 Deploy/Cancel Task 会将 NetworkBuffer Quota 在各 Task 之间做均衡
- 每个 Task NetworkBuffer 需求量和上下游的并发度相关：有最低限制，不够会导致启动失败
- 多余的 NetworkBuffer 在各 Task 之间均分
相关代码
- NetworkBufferPool
- ResultPartitionFactory
- SingleInputGateFactory
可选方案
Deploy/Cancle Task 时对 NetworkBufferPool 进行动态伸缩
- NetworkBuffer 依然需要用户配置上限，无限制的扩张会导致OOM或者GC等问题
- 相比现有实现，只在需要的时候才实际分配 NetworkBuffer，对于浪费的情况可节省部分物理内存
根据 DAG 在 JM/Client 侧计算 TM 中 NetworkBuffer 比例
- 用户只需配置 TM 总资源，NetworkBuffer 比例根据 DAG 计算
- NetworkBuffer 可以计算的相对精确，同样可以节省被 NetworkBuffer 浪费的部分物理内存
- 内存不足的问题从其他方面反映出来：启动时内存不够直接失败、运行时GC等问题，遇到问题之后用户只需加 TM 总内存
备注：NetworkBuffer 数量变少对性能带来的影响待评估
Operator 粒度的资源控制&TM资源异构
Operator 粒度的资源控制：State内存/NetworkBuffer内存/...
根据 Operator 在 JM 中定制 TM 的资源
需要很完善的工具链来做支撑
...
暂无评论...