sync very slow

[GoldMiner817]

System information

Geth version: 16.1
OS; Windows 10 - 64, clean install
MSI z270-A Pro motherboard, MSI armour rx570, 4gb

i've had another sync issue yesterday, but this seems different;

Im still syncing (after almost 24h), i looked around, and it shouldnt take this long.
after last problem, i did --removedb, and started again using --fast --cache=2048 (i haven fast 8gb ram)

so now 24 hours later im here...

INFO [05-06|11:07:29] Imported new chain segment blocks=15 txs=227 mgas=6.781 elapsed=1.999s mgasps=3.392 number=2219050 hash=37e03a…4e7b1a
INFO [05-06|11:07:35] Generating ethash verification cache epoch=75 percentage=84 elapsed=3.049s
INFO [05-06|11:07:35] Generated ethash verification cache epoch=75 elapsed=3.331s
INFO [05-06|11:07:37] Imported new chain segment blocks=66 txs=309 mgas=12.057 elapsed=8.002s mgasps=1.507 number=2219116 hash=c4107f…6b3917

i had to restart, so fast sync is disabled now :(

almost no errors, except these;
WARN [05-06|10:35:34] Synchronisation failed, retrying err="header processing canceled (requested)"

is it possible to download the entire blockchain somewhere?!?

i just want to get started, pls help

fast sync

Actual behaviour

Steps to reproduce the behaviour

Backtrace

[backtrace]

[GoldMiner817]

not sure, how can i tell? 2017-05-06 20:35 GMT+02:00 Felix Lange <notifications@github.com>:

…

How old is your database? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#14433 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AbFaovWizl4EW--c-Y0iVtQBm-5r6kcCks5r3L2BgaJpZM4NSsMw> .

-- Vriendelijke Groeten, Tomas Teunis

[karalabe]

Found the issue. It's a regression from f1069a3 which made some part of the downloader block on database IO. This causes the queue to block and a separate goroutine drop peers for "being unresponsive".

[jpritikin]

Would this affect geth linux-amd64-1.6.1-021c3c28 ? I'm able to sync, but geth is just barely going faster than new blocks are created. I'm only 100 blocks behind, but it's taking hours to catch up. geth CPU usage is around 10%.

UPDATE: I did a fast sync from genesis and things are working sufficiently fast again. It took about 12 hours to sync the chain. It is worrisome that things are almost getting too slow.

[remyroy]

I'm getting slow sync as well on geth 1.6.1 on windows 7 with a HDD. I can barely sync as fast as the blocks are created. I have been stuck on block 3761165 for a while now and I'm getting a bunch of Synchronisation failed, dropping peer warnings. It might be unrelated.

[remyroy]

I'll be waiting impatiently for 1.6.2 and #14460 to solve this issue.

[JGitSchel]

Hi. I have had the same issue with --fast --cache=1024, what I've did is changed the disklocation from c...\Roaming to D:\Ethereum with parameter --datadir="D:\Ethereum". Both HDD's are the same. Pagefile is on D, but somehow on C I got lot of sync errors and pending values fluctuates from 10.000 to 8000 and suddenly 25000 again. After changing to D geth becomes much more stable and rows were updated lot lot faster than before.

(On C: CPU usage of geth was around 5%. Disk max 7MB's (disk = enterprise server disk 160MB/s);
After changing datadir (deleting files in roaming\Ethereum first) to d, geth cpu usages increases to 75%, hdd (D) usage 50MB's and network usage around max. So, it was somehow a good trick ;)

Edit: on C I waited 2 days but still syncing / processing while I didn't know where it was and how much time it needed or how much retries it needed.
After changing to D and restart from 0, it took only 2 hours to get the whole train (4.1 million blocks).

Grz, John

[ElLeopard]

I experienced the same issue. I tried JGitSchel's approach with changing to another disk drive and no I don't see any sync issues anymore and the blocks are pouring in.

[grisu48]

I'm having the same issues. Waiting now for several days already to finish synching the block chain. I've put the .ethereum folder on a separate RAID array that also performs under it's nominal throughput. Get a steady disk write between 5-2 M/s.
Ubuntu 16.04, geth 1.7.2-stable, amd64, go1.9, git commit 1db4ecd

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.