-
Notifications
You must be signed in to change notification settings - Fork 20.2k
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.
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
blockchain sync stalls/ extremely slow #2467
Comments
Same issue, after an initial quick download for the first 200,000 blocks, the syncing really slows to about 256 blocks for every 2 minutes. I've verified that it is not issue with unstable Internet connection, timer, port connection, firewall, etc. Also, when running the --fast, I am getting a synchronization failed, no peers error after a while. It's not efficient to erase db every time this happens, so I am forced to go with the regular download, which after the first 200,000 or so blocks slows down to about 256 blocks every 2 minutes. Any updates on resolution for this issue? |
Could you try 1.4 rc1 https://github.com/ethereum/go-ethereum/releases/tag/v1.4.0 and report back if your issues persist (or not)
|
Good news is that im synced to last block now. I did this via regular download on geth 1.3.6 using --rpc and it took forever(16 days to be precise). I tried everything including trying to add active fully synced enodes manually and nothing helped push the pace. The only significant observation I made was that majority of the syncing took place between 3.30 AM - 8.30 am everyday western standard time. Download speeds ranged between 17 sec - 1min per 256 blocks. Fast sync helps too though you need to make sure you have a stable internet connection and a fast cpu. Any breaks while downloading the state side transactions and you'll have to start over again. Make sure not to interfere in the process until you see the message - 'fast sync complete. auto disabling'. Ppl i know have synced successfully using --fast sync and it took them no longer than a day. Hope this info helps. Good luck! |
Thanks, the slow sync issue described persists while running the geth 1.4 console. I have been opening and re-starting the geth 1.4 console for 2 days now, finally at 1,350,000 blocks...getting there. Averaging about 256 blocks for every 2 minutes. As described earlier --fast does not work efficiently in this situation as I run into "synchronization failed...no peers" error after running --fast for a while, and hesitate to wipe db and start over again, only to encounter the same sync issue. Examples of log: |
Hi, I am trying to download Ethereum blockchain for the past week, and every attempt has failed for one reason or another. Last two attempts appear to have corrupted chains perhaps due to "empty head header set" error(see logs below.) After getting this error, block count has gone down back to 1, and subsequently "geth --fast" gets automatically disabled. Downloading subsequent blocks gets progressively slower, taking anywhere from 2 minutes to 30 minutes to process next block. Would someone from the geth team please have a closer look at following logs. If you require any additional information, please let me know. Environment Geth Version: 1.5.0-unstable [Logs of Third attempt...] I0505 08:54:51.992812 eth/downloader/downloader.go:998] Peer 0b052862d7d52938 [blocks 0.00/s, receipts 0.00/s, states 0.00/s, lacking 0]: empty head header set I0505 08:55:44.690737 core/headerchain.go:294] imported 191 header(s) (1 ignored) in 408.797824ms. #905230 [5fde38ed… / 57cb1179…] [Logs of Fourth attempt...] I0506 16:22:56.366388 core/headerchain.go:294] imported 192 header(s) (0 ignored) in 1.878031918s. #450086 [1fd0243f… / 6808ed53…] **I0506 16:25:57.136551 eth/downloader/queue.go:336] Header #193 [967642fd] broke chain ancestry I0506 16:27:40.481778 core/blockchain.go:959] imported 1 block(s) (0 queued 0 ignored) including 0 txs in 7.250885ms. #3 [3d612266 / 3d612266] I0506 16:29:53.399206 eth/sync.go:180] fast sync complete, auto disabling I0506 16:30:07.016177 eth/downloader/downloader.go:274] Synchronisation failed: peer is unknown or unhealthy |
understand your bandwidth to solve this problem I faced it in here. If you On Sat, May 7, 2016 at 11:26 AM, gsj5 notifications@github.com wrote:
|
@18dew, just for the record, I am running in AWS us-east1, so bandwidth should not be the issue. My problem arises after 80% of the chain is downloaded as expected, and then some corruption occurs around ~700K to ~900K range. Following is the outcome from last nights run. There were three "empty head header set" log entries previous to the fourth entry at 09:13:15.631645 which seems to have renumbered the blockchain from 923850 to 505355. Later on, at 09:49:19.206404, fast sync was disabled, but no log entry as to why? I've attached the log file, in case information presented here does not give a full picture. I0507 09:12:40.483073 core/blockchain.go:751] imported 219 receipt(s) (0 ignored) in 5.715053187s. #923467 [4dca1459… / 88892f23…] |
Agreed this is a different issue all together ... On Sat, May 7, 2016 at 10:27 PM, gsj5 notifications@github.com wrote:
|
go-ethereum is effectively unusable for me right now. Am I wrong to say this? I'm in an Amazon data centre in EU/Ireland. I cannot get it to sync. I am now trying with --fast option. I completely deleted the database and ran:
Amazon security group is wide open. I am now getting this error: I0515 20:03:19.525672 eth/downloader/downloader.go:1130] Rolled back 2048 headers (LH: 110830->108782, FB: 110830->108782, LB: 0->0) Ubuntu 16.04, geth 1.4.3-stable Is this an Amazon issue? Is there traffic shaping/throttling on some ports? Maybe there are a whole load of mis-synced Ethereum instances in these data centres? Maybe these instances need to find enodes further afield? Maybe I'm completely wrong here? |
The issue has been identified. You can watch #2569 for progress. |
Also setting maxpeers is generally a bad idea. Change this only if you know what you are doing. 100 peers requires you to relay and handle 4 times more data! |
Sync issues should be solves by the latest 1.4.6 release. Please check with that and reopen a new issue with details if sync failures still occur for you. |
System information
Geth version:
1.3.6
OS & Version: Windows7 64bit
Commit hash :
Expected behaviour
blockchain should download in a few hours.
Actual behaviour
Iv been trying to sync blockchain on Geth for the past four days now and have only managed to get to block 900 k. Though initially i enjoyed download speeds of a few second per 256 blocks, speeds have dropped to more than two min per 256 blocks over the last two days. Also download keeps breaking off every 20 min or so and i need to restart to resume sync. This continues for a couple of hours a day and then download stops altogether for the remaining hours of day with error - no peers to resume download activity. Im left to wait another 24 hrs before i see some txn activity again.
i have tried everything from syncing system clock with time.nist.gov, enabled port forwarding to 30303, turned antivirus and firewall off etc.. but all in vain.
experiencing this issue on --rpc, --fast & console commands.
Please help!
Steps to reproduce the behaviour
Backtrace
The text was updated successfully, but these errors were encountered: