[
https://issues.apache.org/jira/browse/FLINK-16645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17068919#comment-17068919
]
Piotr Nowojski commented on FLINK-16645:
----------------------------------------
Adding sleep to the throughput benchmarks wouldn't help us, you would be
measuring the sleep time, and how many "sleep(0.1s)" you can do in one second
(spoiler alert: 10 ;) ). All in all, without looking at the code and trying to
figure out the worst case scenario for the change you will introduce, I think
we should be fine with the existing benchmark coverage. We even have one [for
data skew
|http://codespeed.dak8s.net:8000/timeline/?ben=networkSkewedThroughput&env=2](it
writes almost everything to one channel).
> About the counter (...)
Yes, I was hoping for something like that to work :)
> Limit the maximum backlogs in subpartitions for data skew case
> --------------------------------------------------------------
>
> Key: FLINK-16645
> URL: https://issues.apache.org/jira/browse/FLINK-16645
> Project: Flink
> Issue Type: Sub-task
> Components: Runtime / Network
> Reporter: Zhijiang
> Assignee: Jiayi Liao
> Priority: Major
> Fix For: 1.11.0
>
>
> In the case of data skew, most of the buffers in partition's LocalBufferPool
> are probably requested away and accumulated in certain subpartition, which
> would increase in-flight data to slow down the barrier alignment.
> We can set up a proper config to control how many backlogs are allowed for
> one subpartition. If one subpartition reaches this threshold, it will make
> the buffer pool unavailable which blocks task processing continuously. Then
> we can reduce the in-flight data for speeding up checkpoint process a bit and
> not impact on the performance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
