2

For seemingly months now, Geth has been really slow for me. Like, seconds per block:

INFO [07-13|23:35:10] Starting peer-to-peer node               instance=Geth/v1.6.6-stable-10a45cb5/windows-amd64/go1.8.3
....
INFO [07-13|23:37:58] Block synchronisation started 
INFO [07-13|23:38:24] Imported new chain segment               blocks=1 txs=94 mgas=4.861 elapsed=10.425s mgasps=0.466 number=4016552 hash=3b3bee…995b29
INFO [07-13|23:38:36] Imported new chain segment               blocks=5 txs=281 mgas=15.577 elapsed=12.221s mgasps=1.275 number=4016557 hash=77d4ff…e550f6
INFO [07-13|23:38:57] Imported new chain segment               blocks=2 txs=149 mgas=7.680  elapsed=20.224s mgasps=0.380 number=4016559 hash=fae889…3ef261
INFO [07-13|23:39:11] Imported new chain segment               blocks=1 txs=199 mgas=6.555  elapsed=14.478s mgasps=0.453 number=4016560 hash=d14151…5631b9

I have ~3300 blocks to go and it feels like it'll take an hour. Is that normal? What are normal speeds?

I have a powerful and fast machine. i7 with six physical cores. 48GB RAM. My blockchain is stored on a RAID6 array of several 4TB 7200RPM disks hosted by an Areca controller with 4GB cache (battery-backed and write cache enabled). Synthetic tests on the volume show great random read/write latencies and high sustained throughput. Since Geth/Mist used to be much faster (aside of course from the well-known "garbage cleanup" period of the chain) I don't think it's a hardware issue.

Any suggestions?

Is my chaindata corrupted and do I need to delete it and resync my whole blockchain from scratch? Why / how would it become corrupted into a state that still works but is really slow, and should there be any tell-tales in the logs?

If I have to do a full resync, how long ought that take these days?

In case it helps, I also notice either Geth and/or Mist really bog down my machine. When I'm using my PC I'm forced to bump down their CPU Priority and I/O Priority to "Below Normal" to keep things snappy (which of course further slows down my sync).

Also note typing geth console indicates I'm on the forked chain (so not this issue).

INFO [07-14|00:09:01] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 24 ....

I presently have 11 peers, and this feels more like an I/O bottleneck than network one. My command line these days is:

start "Mist" "C:\Program Files\Mist\Mist.exe" --datadir L:\Ethereum --node-datadir="L:\Ethereum" --node-keystore="L:\Ethereum\keystore" --node-cache=512
rkagerer
  • 250
  • 2
  • 13
  • ps. I know similar questions have been asked before and I've tried some suggestions from several. Before you close mine as duplicate please wait to confirm the cross-reference actually solves my issue; thanks! – rkagerer Jul 14 '17 at 07:29
  • similiar topic here: https://ethereum.stackexchange.com/questions/18709/geth-chaindata-copied-syncd-keystore-account-updated-balance-0-heavy-act?noredirect=1#comment20162_18709 and here: https://ethereum.stackexchange.com/questions/19717/geth-syncing-for-24-hours-still-not-done?noredirect=1#comment21158_19717. Good to hear, that you use a real powerful machine. It looks like there is no real root cause analysis possible, cause there was no dev able to go into details. On github there are also issues mentioned: https://github.com/ethereum/go-ethereum/issues/14571 - status: pending ... – pebwindkraft Jul 14 '17 at 07:35
  • 1
    Check how much disk r/w you are using (in task manager). 9 times out of 10 if you have a HDD and not SSD it's a disk throuh put issue. – xgabrielx Jul 14 '17 at 08:34
  • We tried to sync with HDD disks but give up after a few days, switched to SSD and it is working without problems. Developers are aware of the issue, but it is a lowlevel problem with the databse backend, leveldb uses too much io. – Ismael Jul 16 '17 at 18:16

0 Answers0