[ 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)