Parity-ethereum: Latest 1.8.6 sync very slow

[slothbag]

I'm running:

• Which Parity version?: 1.8.6
• Which operating system?: Linux
• How installed?: via binaries
• Are you fully synchronized?: no
• Which network are you connected to?: ethereum
• Did you try to restart the node?: no

Parity 1.8.5 was syncing ok at about 2-3 blocks per second on my SSD drive (the optimum configuration I could find), just updated to 1.8.6 and now getting about 1 block per 10 seconds roughly. Have been running for a few hours, at first all 4 CPU cores were at 100%. Now mainly just one core is at 100%.

[5chdn]

Yes, that's expected behavior, please read the release notes.

If this is an annoyance for you, you can reset your database and sync to a fresh database with the new compaction settings.

[slothbag]

I read the release notes to mean that the DB compaction would eventually complete.. are you saying there is no db compaction and I am forced to re-sync from scratch to enable the db compaction OR do I just need to wait because the compaction is happening behind the scenes? if so how long do you think to compact the db? I have all blocks but not an archive node.

[5chdn]

Either resync or wait, it will finish. I have no estimates though.

[slothbag]

Ok thanks. Wish there was a progress indicator or something :)

[5chdn]

Yeah, that would be nice. @andresilva ;)

[slothbag]

I'm not sure its behaving correctly. So when I start my node with no peers or drop all active peers then the node pretty much drops to 0% CPU usage, which indicates the DB compaction is not happening.

Then when I start up the peers again it syncs very slowly.

[andresilva]

I just did an upgrade this morning and went through a period of about 15 minutes where there were 0 blk/s being imported. After that, it went back to ~3-5 blk/s. Could you try temporarily increasing --cache-size. Maybe something like --cache-size 2048, depending on how much RAM you have available on your system. Let me know if you notice anything different.

Regarding a progress indicator it's not easy to do it. RocksDB does provide support for setting up listeners that are triggered when a compaction is started or completed, but they're not exposed in the C API so we can't really use that feature from Rust (and they don't really provide progress information).

[slothbag]

I set the cache-size to 2048 and it appears to have sped things up about 3x, i'm getting ~100 tx/sec now.

However this is still much slower than what I used to get, which I think was around 500-600 tx/s or about 2-3 blocks/second.

Or another metric is I used to get 10-15 Mgas/s, now its 4 Mgas/s

Edit:
I just bumped up the cache to 4096 and I'm back to my faster speeds again, memory consumption is up around 2 GiB. Can't remember what it was in Parity 1.8.5

[andresilva]

The increase is meant to be temporary, basically it should help RocksDB with whatever it is doing. If eventually performance doesn't go back to normal (without increasing --cache-size) you could try killing the db and doing a re-sync (I warp-synced this morning in about 20 minutes).

[makeworld-the-better-one]

Why is this still happening on the newest version? I'm installing it for the first time and getting 1 block every 10 seconds.

[Tbaut]

You're on an HDD @Cole128, this is simply not manageable anymore for a full node with the size of the chain. Please consider using --light command to use the light client.

[makeworld-the-better-one]

That's too bad. What about --no-ancient-blocks, or is there no point?

[Tbaut]

@Cole128 this has no influence on the sync.

[makeworld-the-better-one]

Oh ok. Thanks anyways. I'll try to run a full node when I get an SSD.