识别flink的反压源头

背景

flink中最常见的问题就是反压,这种情况下我们要正确的识别导致反压的真正的源头,本文就简单看下如何正确识别反压的源头

反压的源头

首先我们必须意识到现实中轻微的反压是没有必要去优化的,因为这种情况下是由于偶尔的流量峰值,TaskManager的GC,定时任务,或者网络波动正好触发引起的,我们要优化的是那种出现持续的反压的情况

其次反压是通过JobManager通过对TaskManager进行定时采样判断TaskManager的cpu状态来确定的,如下:
JobManager对多个采样周期的数据进行平均后得到如下参数:

idleTimeMsPerSecond 每秒空闲时间

busyTimeMsPerSecond 每秒繁忙时间

backPressuredTimeMsPerSecond 每秒反压时间

这里需要注意,既然是多个周期内的平均,需要意识到我们有可能处于这种情况,比如上一个采样cpu处于反压状态,下一个采样处于空闲状态,这种情况其实也值得注意

然后反压的定义如下:

OK: 0% <= back pressured <= 10%

LOW: 10% < back pressured <= 50%

HIGH: 50% < back pressured <= 100%

重新回到正题,比如如下的图:

我们看到Source算子和Flat map算子都处于严重的反压状态,那么导致反压的算子是哪一个呢?是Source算子和Flat Map算子本身吗?答案肯定不是,上游的算子反压都是由于下游算子的消费速度跟不上造成的,所以我们需要查看反压算子的下游算子,下游算子中cpu使用100%的那个下游算子几乎就是导致反压的真正源头,比如这里的keyed aggregate→map算子,cpu使用达到了100%,这才是我们需要优化的算子

PS: flink UI中展示的每个算子的cpu空闲/忙碌/反压值是算子所有算子任务中的最大子任务的cpu空闲/最大子任务的cpu忙碌/最大子任务的cpu反压的值

相关推荐
亿牛云爬虫专家7 小时前
Kafka与Flink打造流式数据采集方案:以二手房信息为例
flink·kafka·数据采集·爬虫代理·数据处理·二手房·定时抓取
Ftrans9 小时前
【分享】文件摆渡系统适配医疗场景:安全与效率兼得
大数据·运维·安全
天氰色等烟雨12 小时前
支持MCP服务的多平台一键发布工具
大数据·github·mcp
AutoMQ12 小时前
技术干货|深度剖析将 Kafka 构建在 S3 上的技术挑战与最佳实践
大数据
AutoMQ13 小时前
技术干货|AutoMQ:在 Kafka 中无需使用 Cruise Control 实现自动分区重分配
大数据
搞数据的小杰14 小时前
spark广播表大小超过Spark默认的8GB限制
大数据·数据库·分布式·spark
isNotNullX14 小时前
数据怎么分层?从ODS、DW、ADS三大层一一拆解!
大数据·开发语言·数据仓库·分布式·spark
时序数据说14 小时前
时序数据库处理的时序数据独特特性解析
大数据·数据库·物联网·时序数据库·iotdb
专注VB编程开发20年15 小时前
WPF,Winform,HTML5网页,哪个UI开发速度最快?
大数据·c#·wpf
一切顺势而行17 小时前
flink 和 spark 架构的对比
架构·flink·spark