[
https://issues.apache.org/jira/browse/BEAM-9167?focusedWorklogId=375994&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-375994
]
ASF GitHub Bot logged work on BEAM-9167:
----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jan/20 00:36
Start Date: 23/Jan/20 00:36
Worklog Time Spent: 10m
Work Description: lostluck commented on issue #10654: [BEAM-9167] Reduce
Go SDK metric overhead
URL: https://github.com/apache/beam/pull/10654#issuecomment-577452380
So per the beam model, Bundles are the unit of a reproducible computation.
If the bundle needs to be re-tried, the runner needs to be able to throw away
the metrics for the bad bundle, so the final counters can be correct. As such,
they are "logical" counters, rather than "physical" counters.
It's the runners job to aggregate metrics for all bundles, for final
presentation, since any given worker isn't aware of the full distributed value
of a counter.
To answer your questions: Yes, each bundle has their own instances of
counters. These metrics get reported to the runner, and are currently
"extracted" from the metric cells via the ToProto function (which requires the
bundleID and PTransformID in question). It's the up to the runner to provide a
way for the user to see them.
There's unfinished work on the "Job Management" proto to provide a common
portable way for SDKs to get metrics from runners. Because of this, the Go SDK
doesn't provide programmatic access to metrics after a job, so it's up to the
user to access the data from the runner directly.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 375994)
Time Spent: 1.5h (was: 1h 20m)
> Reduce overhead of Go SDK side metrics
> --------------------------------------
>
> Key: BEAM-9167
> URL: https://issues.apache.org/jira/browse/BEAM-9167
> Project: Beam
> Issue Type: Improvement
> Components: sdk-go
> Reporter: Robert Burke
> Assignee: Robert Burke
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Locking overhead due to the global store and local caches of SDK counter data
> can dominate certain workloads, which means we can do better.
> Instead of having a global store of metrics data to extract counters, we
> should use per ptransform (or per bundle) counter sets, which would avoid
> requiring locking per counter operation. The main detriment compared to the
> current implementation is that a user would need to add their own locking if
> they were to spawn multiple goroutines to process a Bundle's work in a DoFn.
> Given that self multithreaded DoFns aren't recommended/safe in Java, largely
> impossible in Python, and the other beam Go SDK provided constructs (like
> Iterators and Emitters) are not thread safe, this is a small concern,
> provided the documentation is clear on this.
> Removing the locking and switching to atomic ops reduces the overhead
> significantly in example jobs and in the benchmarks.
> A second part of this change should be to move the exec package to manage
> it's own per bundle state, rather than relying on a global datastore to
> extract the per bundle,per ptransform values.
> Related: https://issues.apache.org/jira/browse/BEAM-6541
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
