我比较倾向于是网络原因。但flink的日志目前无法很明显反映和确认。期望有人从flink反压机制角度考虑下，有没有因为网络“抖动”，比如长连接断开等问题导致反压的case。而且这种情况是否会自动恢复呢？从我的几次经验来看我不重启就不恢复。。。
赵一旦 <
[hidden email]> 于2021年1月6日周三 下午11:43写道：
> 如题，反压的原因，不考虑计算压力大，并行度不合理等问题。
> 比如是否可能和网络也有关呢？
>
> 考虑如下case，A->B->C这么一个拓扑，我A（source）结点反压100%，数据彻底不再发送，但B和C都不反压。但是B、C都是非常简单（不可能存在性能问题）。那这还有什么解释吗？
>
> 比如，A和B之间网络是否可能出问题呢？
>
> 此外，从机器cpu等监控来看，出现反压后，cpu
> idle提升，即反压到cpu利用率直接降低，且cpu在附近实际无升高的迹象。因此不会是瞬间有压力来导致反压。
> 我当前怀疑和网络有关，有人知道如何确认吗。这种case是否有可能自动恢复呢。
>
> 我最近貌似遇到过好几次类似的case，就是反压到直接不发送数据，整个任务彻底停滞。最终解决方式：1
> 停任务（而且每次停任务都会有1个task长期处于canceling最终导致tm失败） 2 停ok并且重启tm后，重启任务。任务运行恢复正常。
>
> 从如上来看，也更进一步证明了不是压力问题，否则为什么我重启就没问题了。不重启则是“一直”反压停滞。
>
>
>
>
>
>
Locked
