Skip to content
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.

Sign up for GitHub

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

Jump to bottom

mining focused on blocks that are too old? #981

Closed
jpritikin opened this issue May 14, 2015 · 7 comments
Closed

mining focused on blocks that are too old? #981

jpritikin opened this issue May 14, 2015 · 7 comments

Comments

@jpritikin
Copy link

I'm not sure if this is what I'm seeing, but it looks like block 333862 was available and geth mined on 333595. What's up with that? That's way too old to be an uncle, isn't it?

I0514 12:24:55.692692    7876 chain_manager.go:628] imported 1 block(s) (0 queued 0 ignored) in 6.422752ms. #333862 [685fbbaf / 685fbbaf]
I0514 12:24:55.694146    7876 worker.go:342] commit new work on block 333863 with 0 txs & 0 uncles
I0514 12:24:58.972846    7876 chain_manager.go:628] imported 1 block(s) (0 queued 0 ignored) in 6.145807ms. #333595 [912153ed / 912153ed]
I0514 12:24:58.972920    7876 worker.go:227] 🔨  Mined block #333595
@jpritikin
Copy link
Author

Mining works sometimes though. Here is an example. I forgot to mention this is geth v0.8.5-2-2128-g7fa7409 on Linux.

I0514 12:38:20.594044    7876 worker.go:342] commit new work on block 333974 with 0 txs & 1 uncles
I0514 12:38:25.571179    7876 chain_manager.go:628] imported 1 block(s) (0 queued 0 ignored) in 5.928247ms. #333974 [618a93ca / 618a93ca]
I0514 12:38:25.572147    7876 worker.go:342] commit new work on block 333975 with 0 txs & 1 uncles
I0514 12:38:30.994029    7876 chain_manager.go:628] imported 1 block(s) (0 queued 0 ignored) in 11.046394ms. #333975 [8dfae93c / 8dfae93c]
I0514 12:38:30.994133    7876 worker.go:227] 🔨  Mined block #333975

@tgerring
Copy link
Contributor

If you're using 0.8.5, I would highly recommend updating to latest which contains many mining improvements. Current version is 0.9.20

@jpritikin
Copy link
Author

Yeah, I'm already using 7fa7409 = v0.8.5-2-2128-g7fa7409

@obscuren
Copy link
Contributor

Did you start mining before it was caught up?

@karalabe
Copy link
Member

Anyone notice this issue ever since? @jpritikin ?

@jpritikin
Copy link
Author

It doesn't happen very frequently, in my experience.

@karalabe
Copy link
Member

I'll close this as hopefully solved by the many fixes since the issue was opened. If you still see something similar, please reopen a new issue with fresh logs.

tony-ricciardi pushed a commit to tony-ricciardi/go-ethereum that referenced this issue Jan 20, 2022
@jeanregisser
Revert "Fix missing reference to libbls_crypto causing linking errors…
3d77844 
… on iOS (ethereum#978)" (ethereum#981)
maoueh pushed a commit to streamingfast/go-ethereum that referenced this issue Sep 13, 2023
@rroblak
Add CLI flags to config LevelDB table/total sizes (ethereum#981)
ebc7dc2 
* Add CLI flags to config LevelDB table/total sizes

I wired up CLI flags to allow configuring LevelDB table and total sizes:
  - `--leveldb.compaction.table.size`, LevelDB SSTable file size factor in MiB (default: 2)
  - `--leveldb.compaction.table.multiplier`, multiplier on LevelDB SSTable file size (default: 1)
  - `--leveldb.compaction.total.size`, total size factor in MiB of LevelDB levels (default: 10)
  - `--leveldb.compaction.total.multiplier`, multiplier on LevelDB total level size (default: 10)

N.B. that the default values for these configs are exactly the same as
before this changset and so Bor behavior should not change unless these
flags are deliberately overridden. Bor/Geth inherited the default values
from [the `goleveldb`
defaults](https://github.com/syndtr/goleveldb/blob/126854af5e6d8295ef8e8bee3040dd8380ae72e8/leveldb/opt/options.go).

We (Alchemy) found it necessary to override these configs as follows to
keep Bor archive nodes tracking the canonical chain:
  - `--leveldb.compaction.table.size=4`
  - `--leveldb.compaction.total.size=20`

These overrides double the size of LevelDB SSTable files (2 MiB -> 4
MiB) and also the total amount of data in each level (100 MiB -> 200
MiB, 1,000 MiB -> 2,000 MiB, etc.). The idea is to have LevelDB read and
write data in larger chunks while keeping the proportional frequency of
compaction operations the same as in the original defaults defined by
Dean and Ghemawat.

Without these overrides we found that our archive nodes would tend to
fall into a "LevelDB compaction loop of death" where the incoming stream
of blockchain data could not be flowed into LevelDB's structure quickly
enough, resulting in the node blocking writes for long periods of time
while LevelDB's single-threaded compaction organized the data.  Over
time the nodes would fall farther and farther behind the canonical chain
head, metaphorically dying a slow node's death.

These configs can be changed on existing node databases (resyncing is
not necessary). LevelDB appears to work correctly with SSTable files of
different sizes. Note that the database does not undergo any sort of
migration when changing these configs. Only newly-written files (due to
new data or compaction) are affected by these configs.

* Update docs

* Adjust line spacing for linter

* Replace map with `ExtraDBConfig`

* Rename `LevelDbConfig` to `ExtraDBConfig`

* Regenerate docs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@karalabe @tgerring @jpritikin @obscuren