You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@flink.apache.org by "Nico Kruber (JIRA)" <ji...@apache.org> on 2018/08/14 10:12:00 UTC
[jira] [Updated] (FLINK-10141) Reduce lock contention introduced
with 1.5
[ https://issues.apache.org/jira/browse/FLINK-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nico Kruber updated FLINK-10141:
--------------------------------
Description:
With the changes around introducing credit-based flow control as well as the low latency changes, unfortunately, we also introduced some lock contention on {{RemoteInputChannel#bufferQueue}} and {{RemoteInputChannel#receivedBuffers}} as well as asking for queue sizes when the only thing we need is whether it is empty or not.
This was observed as a high idle CPU load with no events in the stream but only watermarks (every 500ms) and many slots on a single machine.
was:
With the changes around introducing credit-based flow control as well as the low latency changes, unfortunately, we also introduced some lock contention on {{RemoteInputChannel#bufferQueue}} and {{RemoteInputChannel#receivedBuffers}} as well as some unnecessary reads of atomic booleans like {{inputChannel.isReleased()}} in some scenarios.
This was observed as a high idle CPU load with no events in the stream but only watermarks (every 500ms) and many slots on a single machine.
> Reduce lock contention introduced with 1.5
> ------------------------------------------
>
> Key: FLINK-10141
> URL: https://issues.apache.org/jira/browse/FLINK-10141
> Project: Flink
> Issue Type: Bug
> Components: Network
> Affects Versions: 1.5.2, 1.6.0, 1.7.0
> Reporter: Nico Kruber
> Assignee: Nico Kruber
> Priority: Major
>
> With the changes around introducing credit-based flow control as well as the low latency changes, unfortunately, we also introduced some lock contention on {{RemoteInputChannel#bufferQueue}} and {{RemoteInputChannel#receivedBuffers}} as well as asking for queue sizes when the only thing we need is whether it is empty or not.
> This was observed as a high idle CPU load with no events in the stream but only watermarks (every 500ms) and many slots on a single machine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)