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 > >
