-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extremely slow mainnet sync with pruning enabled #3333
Comments
Please provide more info about your hardware configuration. Total RAM, storage kind (hdd SSD nvme) cpu |
@AndreaLanfranchi sure thing! Important to mention this is with the I scaled up the available resources to 6 vCPU and 8GB RAM (e2-standard-8) and still saw ~blk/s=0.15. Most of the resources were idle: CPU utilization was at 8%; memory utilization was at 13%; disk read still ~0.4MB/s (100 IOPS) and write 0MB/s (0 IOPS). The disk is 512GB pd-standard. Performance is somewhat complicated, but it's roughly equivalent to an HDD. In this configuration it's capable of 60MB/s sustained R/W (and ~400/800 R/W IOPS), which I've confirmed by reading and writing I wouldn't be surprised if the disk is the bottleneck, but what is surprising it how little load erigon is putting on it. If I was seeing this slowness and the disk maxed out, then upgrading to a faster disk would be a no-brainer. Strange that the disk is barely showing any activity, though! Slightly unrelated -- I'd still like to get this node up and running and am trying to think of some creative workarounds to this problem. I found some some full archive torrents -- if I were to grab one of those, would it be compatible with the prune settings I'm running with? |
|
Indeed, after digging a bit more it seems this was a re-hash of #1516.
My goal was only to do the the slow sync on the cheaper HDD drive class, and then upgrade to
I did a quick experiment to test this: I upgraded a snapshot to That's still super slow and doesn't justify the cost of running the expensive cloud drive, so I'm going to do this locally and then upload to my instance when that's ready. Snapshotting is sure to be a killer feature for Erigon -- getting the DB into a workable state has been fairly finicky and resource intensive, but once it's sync'd I've found it to be very reliable without requiring much resources. Snapshots will allow it to more easily run on a larger variety of hardware.
Super helpful, thanks! |
Have fun |
System information
erigon version 2022.01.2-beta (sync started on v2021.12.03)
OS & Version: Linux
Observed behaviour
I've been waiting several weeks for a mainnet node to sync using
--prune=htc --prune.r.before=11184524
as recommended for validators. It's now to a point where it's stalled on stage 5 / execution, and seems to be taking 5-10s to execute individual blocks. At this rate with ~3.6M blocks left to go this will take almost year to finish!My disk is not saturated at all: it's seeing a sustained ~0.37MB/s for reads and no write activity.
Commands:
erigon --prune.r.before=11184524 --prune=htc --datadir=/data --chain=mainnet --state.stream.disable
rpcdaemon --private.api.addr=127.0.0.1:9090 --state.cache=0 --http.addr=0.0.0.0 --ws --http.api=eth,net,erigon --http.vhosts=*
Logs:
The text was updated successfully, but these errors were encountered: