Hello aven.wu: 可以看下各个operator的metrics的指标,比如它的buffers.outPoolUsage、buffers.inPoolUsage、buffers.inputFloatingBuffersUsage、buffers.inputExclusiveBuffersUsage,
- 如果一个 Subtask 的发送端 Buffer 占用率很高,则表明它被下游反压限速了;如果一个 Subtask 的接受端 Buffer 占用很高,则表明它将反压传导至上游。 - outPoolUsage 和 inPoolUsage 同为低或同为高分别表明当前 Subtask 正常或处于被下游反压 ,这应该没有太多疑问。而比较有趣的是当 outPoolUsage 和 inPoolUsage 表现不同时,这可能是出于反压传导的中间状态或者表明该 Subtask 就是反压的根源。 - 如果一个 Subtask 的 outPoolUsage 是高,通常是被下游 Task 所影响,所以可以排查它本身是反压根源的可能性。如果一个 Subtask 的 outPoolUsage 是低,但其 inPoolUsage 是高,则表明它有可能是反压的根源。因为通常反压会传导至其上游,导致上游某些 Subtask 的 outPoolUsage 为高,我们可以根据这点来进一步判断。值得注意的是,反压有时是短暂的且影响不大,比如来自某个 Channel 的短暂网络延迟或者 TaskManager 的正常 GC,这种情况下我们可以不用处理。 - 可以分析出来上游分下游限速里。 - 通常来说,floatingBuffersUsage 为高则表明反压正在传导至上游,而 exclusiveBuffersUsage 则表明了反压是否存在倾斜(floatingBuffersUsage 高、exclusiveBuffersUsage 低为有倾斜,因为少数 channel 占用了大部分的 Floating Buffer)。 分析出来具体那个operator出现反压的问题,然后在具体去分析,看看数据是否倾斜,以及对应算子的jvm情况,看一些算子的线程,可以利用阿里的Arthas在线看下,希望能够帮到你哈。 aven.wu <danxieai...@163.com> 于2020年5月11日周一 下午9:43写道: > Hello 大家好 > 今天遇到个Flink 背压的问题,导致程序完全卡主不在处理数据,从监控页面看是应该是 keyProcess-> sink :alarm state > 处理数据有问题,导致上游 ruleProcess 出现背压。 > KeyProcess 是中定义了一个MapState,每来一条数据会读取和更新state中的内容。Sink 是写入kafka已排除不是kafka的问题 > http://qiniu.lgwen.cn/13F2DE58-98C1-4851-B54A-6BDC3C646169.png, > http://qiniu.lgwen.cn/image/jvm.png > > Dump了 堆栈日志 > http://qiniu.lgwen.cn/docstack.log > 没什么排查的思路,如果方便的话,提供一些排查的思路。 > > Best > Aven > >