Skip to content

Conversation

@seanl-circle
Copy link
Contributor

This redoes #32004 where the new metric I wanted to add was dropped in later revisions.

The reasoning is the same as before: a gauge is only useful at the moment you observe it, but most of us will have metric systems that collect and record the data periodically out of sync with gauge updates. A total value allows us to derive accurate Mgas/s metrics over long periods.

@rjl493456442
Copy link
Member

Can’t you use chain/mgasps? It's not a gauge that only records the instantaneous value, it's a histogram.

// Report the import stats before returning the various results
stats.processed++
stats.usedGas += res.usedGas
chainGasCounter.Inc(int64(res.usedGas))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's inaccurate. Chain processing becomes idle once the initial state sync completes, so it's impossible to derive the MGas/s rate without knowing how long the processor is actively running

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While that may be true most of the time for ethereum, we see cases in downstream forks where geth will lag for signicant periods with the processor always running.

MGas/s is uninteresting when the node can keep up, we want to know what happens when it can't.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants