-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: move exec metrics into executor #10426
Conversation
0a2d9b9
to
1f24b9c
Compare
1f24b9c
to
5602fb4
Compare
Last task is to update grafana |
probably still needs some noodling to get a nicer unit display
b512937
to
1fb9d3f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
MetricEvent::ExecutionStageGas { gas } => { | ||
self.sync_metrics.execution_stage.mgas_processed_total.increment(gas / MEGAGAS) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah this was a bit weird
pub fn metered<F, R>(&self, input: BlockExecutionInput<'_, BlockWithSenders>, f: F) -> R | ||
where | ||
F: FnOnce(BlockExecutionInput<'_, BlockWithSenders>) -> R, | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this seems fine
Removes
ExecutionStageMetrics
and instead adds anExecutorMetrics
used to track things like gas processed, and more in the future.Currently is not integrated into the blockchain tree.
This PR also adds an instantaneous gas/s metric to make this work well with live sync -- currently, if we just added the total gas processed from live sync and did a
rate
in Prometheus over it, performance would look abysmal on live sync, since it would divide the gas processed over the entire slot time (12s).I've implemented this with a
metered
fn that takes a closure and measures the relevant metrics from the input and output. This is ok except it does not handle generic inputs.An alternative I've considered (and still am) was adding some metering to the executor traits instead, since it allows us to handle generic inputs and outputs more easily
Future work could include adding metrics for sloads/sstores, bytecode reads/writes, and account loads/updates
Closes #10397 and closes #9863