[
https://issues.apache.org/jira/browse/FLINK-24189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17412418#comment-17412418
]
Piotr Nowojski edited comment on FLINK-24189 at 9/9/21, 7:55 AM:
-----------------------------------------------------------------
I think the first thing to investigate here would be if the current way of
calculating throughput and the new buffer size is really susceptible for the
data skew problem between different input gates. What would happen currently if
there are two input gates with vastly different throughput? And also what does
that mean?
# Taking into account that we have means that are ensuring fair consumption of
the data between channels/gates/inputs, is it even possible to have data skew
between input gates in the back pressure scenario? As long as both gates are
back pressured, records/s should be the same between both of them and bytes/s
might be different probably only because of a difference in record sizes. Can
this lead to problems or not? How buffer debloating will behave currently if
one input gate has throughput 1KB/s while the other 1MB/s?
# If only one gate is backpressured, current buffer debloating mechanism should
work just fine.
# If there is no back pressure on the other hand, I presume buffer debloating
doesn't matter.
was (Author: pnowojski):
I think the first thing to investigate here would be if the current way of
calculating throughput and the new buffer size is really susceptible for the
data skew problem between different input gates. What would happen currently if
there are two input gates with vastly different throughput? And also what does
that mean?
Taking into account that we have means that are ensuring fair consumption of
the data between channels/gates/inputs, is it even possible to have data skew
between input gates in the back pressure scenario? As long as both gates are
back pressured, records/s should be the same between both of them and bytes/s
might be different probably only because of a difference in record sizes. Can
this lead to problems or not? How buffer debloating will behave currently if
one input gate has throughput 1KB/s while the other 1MB/s?
If only one gate is backpressured, current buffer debloating mechanism should
work just fine.
If there is no back pressure on the other hand, I presume buffer debloating
doesn't matter.
> Buffer debloating for multiply gates
> ------------------------------------
>
> Key: FLINK-24189
> URL: https://issues.apache.org/jira/browse/FLINK-24189
> Project: Flink
> Issue Type: Sub-task
> Components: Runtime / Network
> Affects Versions: 1.14.0
> Reporter: Anton Kalashnikov
> Priority: Major
> Fix For: 1.15.0
>
>
> Right now, the buffer debloat suppose that it works with SingleInputGates
> each of which has a similar load. It needs to support UnionInputGate in case
> of data skew.
> The possible implementation can be the calculation of the throughput
> separately for each gate or calculation of the total throughput but choosing
> the buffer size independently for each gate based on their buffers in use.
> So it looks like the base idea is to keep the same number of buffers in use
> for each gate which means if a gate has a small number of buffers in use we
> decrease the buffer size to force this gate to use more buffers, and we move
> the withdrawn size to another gate with a big number of buffer in use to
> increase its buffer size. In the corner case when all gates(or some gates)
> use all their buffers, the buffer size should be equal in each gate.
> It is highly important to fairly share the throughput among all gates. In
> other words, avoid the situation:
> * gate1 has a low load while gate2 has a high load
> * the small buffer size was set for gate1 and the big buffer size for gate2
> * the load for gate1 increased up to the load of gate2
> * it is impossible to increase the buffer size for gate1 because it is no
> reason to decrease the buffer size for gate2 since the load for it doesn't
> change
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
