13

I start Parity software like so: parity -j

It takes a really long time to sync.

Is there any way to make it sync faster?

jrbedard
  • 524
  • 1
  • 6
  • 15
Vesa
  • 1,322
  • 2
  • 16
  • 30

4 Answers4

25

First of all, you can increase the cache size to speed up block processing, for example to 1GB with --cache-size 1024. Increase it even further if you have more memory available. I'm using 4096.

If you either have a hard drive, or a solid state disk, optimize the database compaction for each type with --db-compaction hdd or --db-compaction ssd respectively.

Make sure transaction tracing is off with --tracing off, however, this should be already the default behavior.

Use the fast pruning mode with --pruning fast which reduces the state size kept in the client. Recently, this is also the default for parity.

Make sure you sync in active mode with --mode active which does never stop actively syncing and importing blocks.

Finally, if you need to fresh sync your chain, do it in warp mode with --warp. This fetches the latest state and latest 30k blocks from the chain and makes your node usable within only a couple of minutes.

In one line:

parity --mode active --tracing off --pruning fast --db-compaction ssd --cache-size 1024
Ayushya
  • 1,698
  • 9
  • 24
q9f
  • 32,913
  • 47
  • 156
  • 395
  • I can test your one-liner but how do I initiate a fresh sync then? – Vesa Dec 04 '16 at 10:09
  • I am trying your one liner but it seems about as slow as the result I get with just -warp. Seems very slow around block #2427470 and the blocks before and after that. I need to know if I should just continue or start over from the beginning with the one liner? – Vesa Dec 04 '16 at 10:19
  • Answering my own question: deleting the whole .parity folder seems to do the trick. Just remember to backup the keys first if anyone else is reading this. – Vesa Dec 04 '16 at 11:29
  • Removing the `~/.parity/906a34e69aec8c0d`` subfolder is sufficient. – q9f Dec 04 '16 at 15:32
  • 1
    --warp is on by default. Explicitly defining the flag gives error Found argument '--warp' which wasn't expected, or isn't valid in this context. So now there is no need to include --warp in the command. – Ayushya Nov 02 '17 at 05:28
4

I believe the --warp flag is what you're looking for, as detailed on their wiki and announced on their blog.

parity --warp
Richard Horrocks
  • 37,835
  • 13
  • 87
  • 144
  • Is it necessary to start over from scratch or can I start with --warp when I already have 70% of the blockchain downloaded through parity -j? – Vesa Dec 03 '16 at 09:39
  • 1
    Deleting the blockchain and resyncing with --warp is faster than waiting for the rest of the 30%. – q9f Dec 03 '16 at 10:28
  • I did not see much speed-up. Please note that I am using 1 GiB RAM to download my own private chain. @Richard Horrocks – alper Sep 11 '17 at 15:42
2

Use this unless you know for sure you need more than what the light client has to offer.

parity --light
  1. Works well for and sets up a highly functional, light node(light nodes in ethereum are much more capable and safe compared to Bitcoin's)
  2. Downloads a chunk of verified blocks and only syncs few blocks after.
  3. If you are using a HDD, this make it possible to sync to the end as the current IO makes it (almost) impossible to sync without an SSD.

Also, running parity --light db kill will delete your existing chain data if you are already syncing.

Vignesh Karthikeyan
  • 1,950
  • 1
  • 12
  • 40
1

I would like to share my configurations that I derived from answer by Afri(5chdn) and have been using for syncing to mainnet. If not anyone else, it shall help me later ;)

config.toml

[parity]
mode = "active"
base_path = "$HOME/parityDatadir"

[footprint]
tracing = "off"
pruning = "fast"
db_compaction = "ssd"
cache_size = 4096

[network]
port = 30303
min_peers = 50
max_peers = 100

startParityMainnet.sh

nohup parity --config config.toml --unsafe-expose &

Ayushya
  • 1,698
  • 9
  • 24