search

smartcontracts / simple-optimism-node

The easiest way to run an Optimism node
MIT License
337 stars 115 forks source link

Syncing from L1 takes weeks #24

Closed tappikone closed 1 year ago

tappikone commented 2 years ago

Syncing from L1 is too slow. Syncing from L2 is the default method for official node quide.

Also using snapshots makes l2geth crash.

Suggesting to change the default method to sync from L2.

smartcontracts commented 2 years ago

Syncing from L1 takes a few days but shouldn't take weeks. Are you using a network volume by any chance? I highly recommend using a machine with a dedicated SSD instead of a network volume. I can add L2 sync as an option though.

smartcontracts commented 2 years ago

Working on L2 sync here #26

tappikone commented 2 years ago

Syncing from L1 takes a few days but shouldn't take weeks. Are you using a network volume by any chance? I highly recommend using a machine with a dedicated SSD instead of a network volume. I can add L2 sync as an option though.

It may very well be some weird problem in my end but can't figure out what. Running local server with SSD, 1gbit fiber and plenty of resources to spare. Also the speed of syncing stays stable and the "blocks left to sync" decreases. No errors.

I now got dtl synced with L2 but again l2geth crashes instantly when it gets a connection to dtl. I've tried fresh install 20 times now.

"simple-optimism-node-l2geth-1 | INFO [11-12|07:00:04.939] Connected to upstream service simple-optimism-node-l2geth-1 | panic: runtime error: invalid memory address or nil pointer dereference simple-optimism-node-l2geth-1 | [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0xbe9680]"

smartcontracts commented 2 years ago

Hmmm... can I see your environment variables? (with sensitive info removed)

tappikone commented 2 years ago

I don't think there's anything interesting. Just filled the three with alchemy nodes. Could be faster if I ran my own L1 node?

smartcontracts commented 2 years ago

Usually memory and disk times on the L2 side are the bottleneck. You might be able to speed things up by allocating more RAM to the geth cache. Just add --cache=16384 \ (or however much memory you want to allocate in MB) to l2geth-start.sh.

smartcontracts commented 2 years ago

If you're syncing from L2, make sure you set ROLLUP_BACKEND=l2 in your Geth environment

smartcontracts commented 1 year ago

Closing, not much I can do here beyond the notes listed above