Hi Gagan, What flink version do you use? And have you checked the buffers.inputQueueLength for all the related parallelism (connected with A) of B? It may exist the scenario that only one parallelim B is full of inqueue buffers which back pressure A, and the input queue for other parallelism B is empty.
Best, Zhijiang ------------------------------------------------------------------ From:Gagan Agrawal <agrawalga...@gmail.com> Send Time:2019年1月7日(星期一) 12:06 To:user <user@flink.apache.org> Subject:Buffer stats when Back Pressure is high Hi, I want to understand does any of buffer stats help in debugging / validating that downstream operator is performing slow when Back Pressure is high? Say I have A -> B operators and A shows High Back Pressure which indicates something wrong or not performing well on B side which is slowing down operator A. However when I look at buffers.inputQueueLength for operator B, it's 0. My understanding is that when B is processing slow, it's input buffer will be full of incoming messages which ultimately blocks/slows down upstream operator A. However it doesn't seem to be happening in my case. Can someone throw some light on how should different stats around buffers (e.g buffers.inPoolUsage, buffers.inputQueueLength, numBuffersInLocalPerSecond, numBuffersInRemotePerSecond) look like when downstream operator is performing slow? Gagan
