Seems a pi with geth no longer manages to sync #10
Comments
|
First I had block synch problems playing with the options / restarting didn't help. Now I'm at the same stage as @cryptogohan - the count for "Imported new block headers" is low but it seems that "Importing new state entries" will never end. This is most likely caused by too slow disk i/o as explained here: ethereum/go-ethereum#16251 . It also matches what I see in the system - the disk i/o is 100% most of the time. |
|
Hi, Can you give us more info on your setup? (RAM, SSD, etc). We will enable the snap sync on the next release which should make it easy get the node synced. With fast sync and an 8 GB RAM Raspberry Pi (with a decent SSD) you should get it in sync in 2-3 days. (State entries can go as far as 800 Million today). |
|
By looking at the log and measuring the time I came up with the current speed of 6000 state entries processed per minute. However, I'm currently at 700 millions and the machine is running for 6 days. So it may be that it's just slowing down. I'm using Raspberry Pi model B with 8GB of RAM. "Use an USB 3.0 External Hard Drive Case with a SSD Disk. In our case we used a Inateck 2.5 Hard Drive Enclosure FE2011. Make sure to buy a case with an UAS (USB Attached SCSI) compliant chip..." Would you know how to check if my enclosure is UAS compliant or not? |
|
Could you run:
And paste it here? |
|
|
Ummh, Kingston. Based on our experience, it's performance is terrible with the Rpis. I'm not saying I'm 100% sure this is the problem but it is the most probable cause. You can do an iozone3 disk test to check the disk performance (but you need to stop geth service first). Paste the results here. |
|
(I'm the alt of cryptogohan. Transitioning to this handle.) Yea, I'm on the 4gb model I'm afraid. I suppose I'll just sell it then. I got the recommended Samsung SSD I think.
Latest geth logs: Looking at system resource use it looks like mem is the bottleneck more than IO. |
|
In my case the problem was with the external SSD enclosure. It was causing slow-down and even IO errors. Once I've replaced it with the new one, the synchronization finishes. |
|
I have tried a different approach and used RockPi with 4GB RAM but NVMe attached directly to it. The synchronization was quick quick (about a week) and the node catch up with new blocks: But I guess this is not over, because web3.eth.getBalance still returns 0. What I see in the logs is now "State heal in progress": This has been running for over a week now. Would you know what are accounts, slots, codes, nodes and pending there? |
|
Yeah, it is not over, healing is part of the new snap sync mode so it will take some time. 4 GB is really tight, please let us know if it finishes the sync and how long it takes. Thanks! |
|
Hi @diglos, Iozone test: And here is the I'm running it on a 8Gb RPI4 version, so I suppose the problem is either coming from the enclosure or the cable, when I look at grafana, I can see that the max writing speed is around 30 MB/s but usually it's writing at 20 MB/s so I wonder if it could be the root of the issue. Any SSD enclosure to recommend? |
|
Hi, sorry I missed this comment.
20/30MB/s are expected figures (as there a lot of small read/writes). Iozone shows that performance is good. Are you doing ok with the node? |
Thanks for replying! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
It's been a month. Recommended hardware (4gb pi + active cooling + 1TB ssd + 200mbps connection). Block headers look good, state trie looks neverending.
Going to try OpenEthereum now. From what I understand it wouldn't get stuck on the state trie. Shame that there's no Grafana dashboard, maybe I can enable metrics and pluck one from somewhere.
This issue can be closed, just thought it be good to report in case others try setting up a Pi + Geth and find they're still not synched weeks later.
Perhaps someone also has suggestions for how to get the pi synched. Running with default arguments:
The text was updated successfully, but these errors were encountered: