lambo4jos
commented
1 year ago looks like it has finally synced so I will close this. didn't see much in the docs about how long it would take to sync for an eth 2.0 execution and consensus layer node on a the same RPi, but it does eventually sync. will try splitting up the beacon node to its own RPi to free up resources for geth to operate independently
I should note that it took nearly 10 days for it to finally sync
I am running both geth and ligthouse beacon on the same raspberry pi 4 model b node with 8gb RAM, and a 2TB nvme gen4 disk, that supports 5150mb/s reads, and 4850 mb/s writes, with a 1.2 gbe internet connection
Geth is stuck around 60 blocks below a complete sync, which took about 2 days to reach this state, and has been healing trienodes for about a week since. Pre-merge, geth on its own was able to reach 60 blocks below a complete sync in 2 days, and took about 1 day to heal trienodes to reach a complete sync
I am not running a lighthouse validator node, as I only need beacon so that geth will sync so that I can use the node to make API queries against
I tried various different --cache settings for geth, such as 1024, 2048, 3072, 4096 etc, and nothing seems to help. I am wondering if the RPi 4b with 4 cores and 8gb RAM is not powerful enough to run both geth and lighthouse beacon on the same node, preventing geth from having enough resources to reach a full sync. Maybe it is a resource constraint issue?
I'd like to ask if anyone else is having this issue and if there is a way to potentially resolve the issue, or if you are able to successfully run both geth and lighthouse together on the Rpi4b
Any guidance is most appreciated. I may try to upgrade to the latest unstable version of geth to see if that might help resolve the issue, as some people have reported the issue could be with geth v1.10.25