So I've been trying to sync to the full blockchain from scratch with Geth for over a week, and towards the end it's too slow to ever catch up to the current block. I don't think the developers have tried syncing from scratch in a while, because AFAIK it's no longer possible, at least on average consumer grade hardware. I've tried --fast and increasing the cache to 4096, but even that slows to a crawl toward the end and the blocks are processed, at best, at the same speed as the new ones coming in. It's usually a bit slower.
Anyone want to help out on this one? I realize one can sync quickly with the --light blockchain, but some of us want the real mccoy.
1 ·
Comments
It requires SSD with space available - presently 102Gb. and it takes a few days, anywhere from 2 to 10 days. My internet speed is 150mbps and wired.
Just regular client without any flags.
Now I run it every 3-4 days and it takes around 3-4 hours to synchronise again.
mgasps=0.2xx
or similar in low blockcount low transaction chain segments. It seems there may be some hope, depending on what you're dealing with. Are you at that slowdown at2283397
and the subsequent clearing contract around2675000
?see also: https://ethereum.stackexchange.com/questions/9883/why-is-my-node-synchronization-stuck-extremely-slow-at-block-2-306-843 That storage usage was spotted at
2706667
on the full block mode sync, for what it's worth.~/.ethereum/geth/chaindata
just grows and grows. I'm at full block4336000
now, geth's chaindata has risen to about 455GB spread across 291780 individual .ldb files. It's exceeded my available contiguous SSD storage volume, but fortunately it responds well enough to having relatively static old individual .ldb files symlink'd off to slower storage (e.g. HDD or even HDD-based NAS).Best of luck getting caught up to the present chain state! I'm not sure why nobody else has been talking about this remarkable storage demand, when most of the discussion I can find online suggests it "should" take up less than 128GB. This thing makes Bitcoin's full blockchain (~165GB) look tiny in comparison. If it's just something I'm doing wrong somehow, hopefully I can figure that out or someone here can point out my error.
Well, I'll keep at it because I do believe in the open, decentralizated, pro-social, pro-community world that I understand the Ethereum ecosystem aims to champion and promote. Let's build a better world, together, and then inhabit it.
4336000
,~/.ethereum/geth/chaindata
has grown to over 450GB spread acros over 291782 individual .ldb files.It seems like a quite remarkable level of storage, much larger than Bitcoin (which is presently ~165GB), and it leaves me wondering if I've made some error that it is nobody else has been mentioning half-TB storage needs for a geth-based Ethereum node in 2018.
Fortunately, geth does seem to respond well to having individual .ldb files symlink'd off to slower (e.g.: HDD or HDD-backed NAS) storage, so you don't actually require a 512GB+ SSD to get through this at > 1.0 mgasps.
Well, it's a bit painful but I do earnestly believe in the decentralized, pro-community, pro-social world that I understand the Ethereum ecosystem can help champion and promote. Let's build a better world together, and then inhabit it and flourish.
state entries continue and data builds up.
keep getting many invalid hash chains from multiple peers that all have the same invalid difficulty from same want difficulty
Have funds in wallet from mining that need access to, Please advise been started over clean 0 blocks geth --fast --cache 2048