3

I've tried resetting the sync and it still comes to a screeching halt around block number 2.4m. I know about the attacks on Ethereum around those blocks, but this is ridiculous: super slow I've been syncing for 4 days now, the first day I went from #0 to about #2.2m second day I got to ~#2.4m and the last 2 days it hasn't even got half way to #2.5m. Isn't Parity supposed to be significantly faster than this? I tried syncing with Geth first and it got permanently stuck at 141 blocks left in the same time it's taken parity to slow down to a highway parking lot. Now I can't even get Geth to get back to where it was, since I reset it anyway. Is there any other options to get this thing synced faster? Like downloading someone else's block chain copy or something? This is how I run Parity: parity --min-peers=50 --max-peers=100 --cache 4096 --geth

Update: By the end of the 6th day, it sped back up because it past the troubled range. Now it's stalled again with less than 200k blocks left. Yay me. Any ideas?

Improve this question

3 Answers 3

Reset to default
4

I'm being totally serious when I say that the best thing to do is simply be patient. As long as you're getting new blocks, there's not much to do. If on the other hand, Parity continues to report the same block, then you can kill it and restart it.

Blocks between around ~2286900 and ~271800 are very, very slow because of the DDOS attack in Sept/Oct 2016. What happens is the blocks are very long playing, so if you repeatedly kill the node while it's processing a block and restart it, you're making it take that much longer because it has to start over on that block. Once it gets past ~271800 it should speed up again.

Improve this answer
4
  • I have less than 2k remaining. For every 1 block synced, 2 more are created, until I get close to ~1600 blocks remaining and it zips down to ~1400. It's getting ridiculous watching the number go up and down between 1400 and 1600. I'm about to say the hell with Ethereum because it's so slow. Last time I used BTC or LTC it took ~4 days to sync the stock client. Is there no electrum for ethereum?!?
    – Timberwolf
    Jan 3, 2018 at 8:55
  • It’s brutal. I admit. I just noticed Parity closed a bunch of issues related to the database, so maybe there’s hope with the next release. Sorry I can’t be of more help.
    – Thomas Jay Rush
    Jan 3, 2018 at 15:18
  • What makes those blocks slow to-this-day to sync? A fresh archival parity node on 2.1.4 slows down in that block range, but only processes about 0.5 blk/s and 2.5tx/s. It's not like there are a billion tiny transactions that have to be validated...in fact parity is barely validating any txns at all...
    – xref
    Nov 1, 2018 at 7:24
  • Did a little more digging, it was a DDoS making millions of bogus accounts and traces which causes slowness, not the raw # of txns themselves. More info here: medium.com/@tjayrush/… and here: ethereum.stackexchange.com/questions/9883/…
    – xref
    Nov 1, 2018 at 7:34
0

Sounds like its this ongoing issue. Before it's fully fixed, probably try some of the workarounds suggested in that thread (won't necessarily work - none worked for me).

Improve this answer
0

I'm in the home stretch right now syncing with Parity v1.7.3 and it's been going now for almost 24hrs. At its current rate of about 2-5blks/s it probably has another 20 hrs to go. I agree with current responses that you just have to wait it out. In my research I've seen a lot of responses focus on the computer, especially the HDD but this clearly seems to me to be a limitation of the Ethereum network peers.

When you think about it you're getting that data piecemeal from distributed peers. It's nothing like downloading a large file from a server. My system is connected with about 25 peers. Those are nodes that are probably very busy trying to mine Eth and aren't going to focus on getting you or me up to date so we can compete with them. I'm not saying they altered their code, but a review of the code might help explain the slowness to sync.

I've heard that you can find compressed files of the back blocks and download the file and install it to sync more quickly. Anyone know if that works?

Improve this answer
2
  • If you're running with an HDD, in the long run you'll probably be fighting a losing battle. Also note that it's not necessarily writing the raw data to disk as it comes off the line that's the problem: it's the I/O associated with replaying/verifying everything in the state data, which is invariant of anything related to peers or downloading. Even if you could download the compressed data from a single source, you're still going to see the massive amounts of I/O in verifying the transaction data.
    – Richard Horrocks
    Jan 12, 2018 at 17:04
  • I'm using an SSD. The resource usage per task manager is pretty much constant at about 50% utilization of the SSD and about the same for memory (8GB out of 16GB). CPU stays around 20%. But the blocks/s varies over time and is now dropping. This morning, now that it's getting close, the rate is down to 1 to 2blk/s. The block processing rate doesn't seem to correlate with local resource usage. My internet connection is FIOS at almost 1gb/s.The only other factor I can think of would be the peer network?
    – Joe Mattioni
    Jan 13, 2018 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.