Node synced but eth.blockNumber still shows 0

[khelle]

System information

Geth version: Geth/v1.0.7-46d185b4-20210403/linux-amd64/go1.14
OS & Version: Ubuntu 16.04

Options Used to Run Node:

/home/bnb/node/geth --cache=4096 --rpc --rpcapi eth,web3,debug,personal --rpcaddr 0.0.0.0 --rpcport 16001 --port 30311 --config=/home/bnb/config/config.toml --datadir=/home/bnb/.ethereum --syncmode=fast

Expected/Actual behaviour

So, my node has been syncing in fast mode, for over a two weeks on high-end SSD-based server, and syncing shows it should be done:

> eth.syncing;
{
  currentBlock: 8184802,
  highestBlock: 8184886,
  knownStates: 200634949,
  pulledStates: 200634948,
  startingBlock: 0
}

But eth.blockNumber shows 0 each time. I can easily query the blocks with eth.getBlockByNumber and it shows right data as expected.

Note that currentBlock is usually ~100 blocks below highestBlock, but both of them are increasing all the time, it is not stuck. HigherBlock is equal to actual highest block reported by blockchain so it seems it already caught up.

How can I fix this so eth.blockNumber shows actual synchronization block?

[n8twj]

Regular SSD's won't cut it... Must be an NVMe drive.

[khelle]

I am using SSD NVMe drive. Still after a three weeks it's still syncing. The difference between highestBlock and currentBlock stays at around 80-120 blocks, and both are incrementing all the time. However, I can even fetch newest blocks with API, so it seems the node already HAS that data, but still getBlockNumber returns 0. Is is a bug?

[n8twj]

If it doesn’t sync after 48 hours, it so t ever sync up. Something about your system is not fast enough. IOOPS most likely is not enough.

On Tue, Jun 15, 2021 at 06:01 Kamil J. ***@***.***> wrote: I am using SSD NVMe drive. Still after a two weeks it's still syncing. I can even fetch newest blocks with API, so it seems the node HAS that data, but still getBlockNumber returns 0. Is is a bug? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#283 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGIZ4ITIPC6EAII6Z3B5X3TS4QIZANCNFSM46PJ5LIA> .

-- Typos courtesy of my iPhone...

[khelle]

Are there any steps that I can follow to make sure it is in fact my hardware being too slow? The answer along the lines "it works for me" does not suffice.

I am using high-end dedicated server to host BSC node exclusively with 4 TB NVMe SSD, so I doubt that it is the reason, especially taking into consideration that lag between current and highest block is not increasing. If the server was inadequate, the gap should widen, which is not happening.

[blockchen-admin]

Hi,
I'm having the same problem, syncing is not finished.

with 2 servers
Synchronization is finished on one server, but the other server, which has higher performance than the synchronized server, is still not synchronized.

I also have a gap of about 100 blocks.

[zhongfu]

@khelle @blockchen-admin two things off the top of the mind:

• are you using directly-attached, dedicated storage? (i.e. not over the network, or AWS EBS, etc)
• are you using zfs? (the large default recordsize will probably wreck i/o performance, although I'm not sure if a smaller recordsize will make it better either. I personally use xfs -- syncs fine even on a high-end, enterprise SATA SSD -- although I've heard that ext4 and btrfs will work too.)

[khelle]

@zhongfu I am using directly attached SSD NVMe disk. The machine I am using is one of higher tiers dedicated server running inside dedicated datacentre. The filesystem that is being used is ext4. The machine does not do anything other than running BSC node. Htop shows me there is not that much activity going on anyway, so hardware is not utilized to its 100%.

Sync is being done because the current states data is being updated and I can fetch blocks from node easily. The node is always around ~100 blocks behind. The blockNumber shows 0 after I believe around 4 weeks of syncing.

What's wrong? Do I need supercomputer worth thousands of $ per month to run this? And if yes, then why even on the server I am having now, the hardware is not used 100%? Are any node developers actually looking here and solving people issues or are those forums abandoned?

[zhongfu]

@khelle

@zhongfu I am using directly attached SSD NVMe disk. The machine I am using is one of higher tiers dedicated server running inside dedicated datacentre. The filesystem that is being used is ext4. The machine does not do anything other than running BSC node. Htop shows me there is not that much activity going on anyway, so hardware is not utilized to its 100%.

I'll take your word for it then -- that you're running on a (baremetal?) dedicated server with a NVMe drive that isn't shared by anyone at all.

In that case... perhaps network bandwidth? It might help if you let us know which provider you're renting your server from, and which of their offerings you're using.

What's wrong? Do I need supercomputer worth thousands of $ per month to run this?

All of my nodes are running on computers that cost less than <$500 apiece, lol

And if yes, then why even on the server I am having now, the hardware is not used 100%?

(Fast-)syncing is primarily an I/O intensive task, it's not going to peg all your cores at 100% usage (or even anywhere close to that)

Are any node developers actually looking here and solving people issues or are those forums abandoned?

Who knows?

[khelle]

What I tried up to this point using v1.0.7:

• full sync - run out of space on my machine
• fast sync + snapshot - run out of space on my machine
• fast sync - neverending sync that is always around 80-120 blocks behind

[khelle]

I was finally able to sync the BSC node. I had a little more free time lately so I decided to use v1.1.0 instead of v1.0.7. That alone was able to solve my issues. On the new release it synced without any problems from scratch in less than 12h. Now everything is working correctly. It seems v1.0.7 has some major problems with connecting to the network. I suppose the documentation should be then updated to mention it, and maybe retag v1.1.0 from beta to stable or rc so people will now it is safe to use it.