long time importing few blocks and then stuck #1192
Comments
|
Could it happen that you had/have a very low bandwidth connection? I'm seeing the same error over and over again, all peers timing out on retrieving 2048 hashes. That amounts to having a lower bandwidth than 13KB/s. You can play around with increasing this timeout in eth/downloader.go -> hashTTL to maybe 10-15 secs and see if that solves it for you? |
|
I noticed the same thing with my node. Resetting geth seems to help and the node will eventually catch up, but after a while it falls behind and eventually stalls out. My connection is around 100KB/s. I also notice I usually have less than 3 peers and usually 1 or 2 only. My node is "Master Shake" on stats.ethdev.com. |
|
This is different from #1190 (this happened after starting again from block0). I don't think there were any issues with network connection since I was doing other stuff online ok. As cjphilpot mentions, I think I restarted geth, maybe a few times, and eventually it was able to get more blocks. I check peercount when trying to fix this at the time and it was not part of the issue, otherwise I would mention the low peercount. Next time I may try "increasing this timeout in eth/downloader.go -> hashTTL to maybe 10-15 secs". IIRC in gitter, a pi2 also had this issue? (This is on a normal machine but could be helpful to know how the pi2 was resolved.) This is different from #1191 (different node, box). |
|
@ethers Did you try upgrading to current develop? It features the new sync protocol eth/61, which should be light years more stable than the old one. If it works out for you, I'll maybe close this issue. If you have issues with that though, could you open a fresh issue? This is kind of stale already. |
* celo-blockchain cherry-pick from upstream: p2p: new dial scheduler (ethereum#20592) Conflicts: p2p/dial.go p2p/server.go p2p/server_test.go * p2p: new dial scheduler This change replaces the peer-to-peer dial scheduler with a new and improved implementation. The new code is better than the previous implementation in two key aspects: - The time between discovery of a node and dialing that node is significantly lower in the new version. The old dialState kept a buffer of nodes and launched a task to refill it whenever the buffer became empty. This worked well with the discovery interface we used to have, but doesn't really work with the new iterator-based discovery API. - Selection of static dial candidates (created by Server.AddPeer or through static-nodes.json) performs much better for large amounts of static peers. Connections to static nodes are now limited like dynanic dials and can no longer overstep MaxPeers or the dial ratio. * p2p/simulations/adapters: adapt to new NodeDialer interface * p2p: re-add check for self in checkDial * p2p: remove peersetCh * p2p: allow static dials when discovery is disabled * p2p: add test for dialScheduler.removeStatic * p2p: remove blank line * p2p: fix documentation of maxDialPeers * p2p: change "ok" to "added" in static node log * p2p: improve dialTask docs Also increase log level for "Can't resolve node" * p2p: ensure dial resolver is truly nil without discovery * p2p: add "looking for peers" log message * p2p: clean up Server.run comments * p2p: fix maxDialedConns for maxpeers < dialRatio Always allocate at least one dial slot unless dialing is disabled using NoDial or MaxPeers == 0. Most importantly, this fixes MaxPeers == 1 to dedicate the sole slot to dialing instead of listening. * p2p: fix RemovePeer to disconnect the peer again Also make RemovePeer synchronous and add a test. * p2p: remove "Connection set up" log message * p2p: clean up connection logging We previously logged outgoing connection failures up to three times. - in SetupConn() as "Setting up connection failed addr=..." - in setupConn() with an error-specific message and "id=... addr=..." - in dial() as "Dial error task=..." This commit ensures a single log message is emitted per failure and adds "id=... addr=... conn=..." everywhere (id= omitted when the ID isn't known yet). Also avoid printing a log message when a static dial fails but can't be resolved because discv4 is disabled. The light client hit this case all the time, increasing the message count to four lines per failed connection. * p2p: document that RemovePeer blocks * les: add bootstrap nodes as initial discoveries (ethereum#20688) * celo-blockchain addition: make static dials exempt from the maxDialPeers limit Static peers are ones we explicitly want to connect to, and so should not be subject to this limit. This is especially important since connections between validators/proxies and other validators/proxies rely on this being so, and because that's how it was prior to the new dial scheduler from upstream. * celo-blockchain addition: Add tests for two untested RemovePeer() scenarios Co-authored-by: Felix Lange <[email protected]>
…um#1208) This increment was moved lower down in the function, but not removed here in the conflict resolution in ethereum#1192.
all: sync with upstream v1.10.22
develop commit 43ceb0f
Run geth, it took a long time to import just 44 blocks, then no longer getting any blocks for almost an hour.
Rest of the logs:
The text was updated successfully, but these errors were encountered: