下游算子的处理代码排查，往往是下游处理能力不足
在2020年5月12日 09:32，shimin huang<
[hidden email]> 写道：
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 <
[hidden email]> 于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.pngDump了 堆栈日志
http://qiniu.lgwen.cn/docstack.log没什么排查的思路，如果方便的话，提供一些排查的思路。
Best
Aven
Locked
