Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions core/blockchain.go
Original file line number Diff line number Diff line change
Expand Up @@ -67,6 +67,7 @@ var (

chainInfoGauge = metrics.NewRegisteredGaugeInfo("chain/info", nil)
chainMgaspsMeter = metrics.NewRegisteredResettingTimer("chain/mgasps", nil)
chainGasCounter = metrics.NewRegisteredCounter("chain/gas/total", nil)

accountReadTimer = metrics.NewRegisteredResettingTimer("chain/account/reads", nil)
accountHashTimer = metrics.NewRegisteredResettingTimer("chain/account/hashes", nil)
Expand Down Expand Up @@ -1888,6 +1889,7 @@ func (bc *BlockChain) insertChain(chain types.Blocks, setHead bool, makeWitness
// Report the import stats before returning the various results
stats.processed++
stats.usedGas += res.usedGas
chainGasCounter.Inc(int64(res.usedGas))
Copy link
Copy Markdown
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
Copy Markdown
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.

witness = res.witness

var snapDiffItems, snapBufItems common.StorageSize
Expand Down