[
https://issues.apache.org/jira/browse/BEAM-7745?focusedWorklogId=631110&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-631110
]
ASF GitHub Bot logged work on BEAM-7745:
----------------------------------------
Author: ASF GitHub Bot
Created on: 29/Jul/21 12:24
Start Date: 29/Jul/21 12:24
Worklog Time Spent: 10m
Work Description: steveniemitz removed a comment on pull request #15235:
URL: https://github.com/apache/beam/pull/15235#issuecomment-888518829
I'm not sure why the Wordcount job is failing and can't really see any
output from it. The error is just:
`Dataflow job 2021-07-28_10_43_24-13457376805023557994 terminated in state
RUNNING but did not return a failure reason.`
edit: I ran this manually and it writes the files but the job doesn't
terminate. I'm not sure how it's supposed to know to terminate since it runs
in streaming mode?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 631110)
Time Spent: 1h (was: 50m)
> StreamingSideInputDoFnRunner/StreamingSideInputFetcher have suboptimal state
> access pattern during normal operation
> -------------------------------------------------------------------------------------------------------------------
>
> Key: BEAM-7745
> URL: https://issues.apache.org/jira/browse/BEAM-7745
> Project: Beam
> Issue Type: Improvement
> Components: runner-dataflow
> Reporter: Steve Niemitz
> Priority: P3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> I spent some time tracking down sources of uncached state fetches in my job,
> and one large category was the interaction of StreamingSideInputDoFnRunner +
> StreamingSideInputFetcher.
> Basically, during standard operations, when the main input is NOT blocked by
> the side input, the side input fetcher will perform an uncached state read
> for every input element. Changing it to cache the blockedMap state gave me a
> ~30-40% increase in throughput in my job.
> The interaction is a little complicated, and there's a couple optimizations
> here I can see.
>
> Primarily, the blockedMap is only persisted if it is non-empty. Because the
> WindmillStateCache won't cache a null value, this means that the "nothing is
> blocked" signal is never actually cached, and will issue a state read to
> windmill for each input element. The solution here seems like it is to
> persist an empty map rather than a null when there are no blocked elements.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
