Parity warp sync is no longer very warpy.
MicahZoltu opened this issue · 80 comments
I'm running:
- Parity version: 1.7.0
- Operating system: Windows
- And installed: via installer
I just installed Parity onto a brand new computer with a fresh install of Windows 10 Pro. The computer has Hyper-V enabled and Docker, but otherwise is a stock Windows 10 Pro computer of reasonable power (Dell XPS 9560). It is connected via wireless ab/n 5GHz to a nearby router and is able to easily max out my internet connection (100Mb/s down, 12 Mb/s up).
It launched after install about 12 hours ago and at first warp sync was moving quickly. However, at about 91.46% warp restore (pretty shortly into the initial sync) the restore progress froze at 91.46% and best block started counting up from 0. About 12 hours later it is only up to best block 3,594,000.
On previous versions of parity launching Parity with no chain data and no extra parameters (other than the default ui) would result in a full restore in about an hour on a less powerful computer.
Over the course of this time, it has written 2 TB to disk (presumably mostly overwrites since I only have a 1TB disk) and it has read almost nothing off of disk (42MB). It has received ~7GB over the network and only sent about 300MB.
It seems there are several issues floating around about Parity's footprint (one of them even by me) and I apologize if this should have been a comment on one of those, but none of them expressed the same symptoms so I wasn't sure.
Some cumulative numbers across the lifetime of the process:
Upon further inspection, it appears that the initial launch of Parity post-install is ui --warp --mode=passive (this differs from the start menu shortcut that is created which is just ui).
As an update, I just restarted my computer (for unrelated reasons) and Parity crashed on startup the first time, then on re-launch it started the Warp Restore over again from 0% and my best block says 3,831,654 (where it was at time of restart).
Perhaps this should be a separate issue (let me know if so) but it would seem that restarting in the middle of a warp restore causes problems.
Please share some logs. It's hard to tell why the warp sync is stuck at a certain state / block.
It has recovered at this point, is it possible to see a log history or are they pruned over time? If not, the repro steps are:
- Buy new computer.
- Re-install OS without manufacturer bloatware.
- Install Chrome, Docker, Parity.
- Let it sit warp syncing for a bit.
- --> Notice that it gets stuck.
If I end up resetting my chain and reproducing this myself I'll try to enable the log capture during sync.
Actually, I can reproduce this on different setups. Sometimes it feels random. https://gist.github.com/5chdn/683b905aa410de0232690fd9ddaf32fb
The current state grew to around 1.3 GB and we have 6.3 million unique addresses. https://etherscan.io/chart/address
Not sure what the future will bring for warp sync, but it's quite probable that end-users will switch to light mode by default on most machines.
Yes, that's my issue #6371. Is there any way to restore parity account in other ethereum-based wallet?
Just noticed that operating mode is passive. Should it be that way?
[27.08.2017, 02:15:13] Syncing snapshot 2/555 #2423899 20/25 peers 7 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 8 req/s, 121 µs
[27.08.2017, 02:15:03] Syncing snapshot 2/555 #2423899 19/25 peers 6 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 7 req/s, 119 µs
[27.08.2017, 02:14:53] Syncing snapshot 2/555 #2423899 19/25 peers 5 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 6 req/s, 118 µs
[27.08.2017, 02:14:43] Syncing snapshot 2/555 #2423899 19/25 peers 6 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 4 req/s, 383 µs
[27.08.2017, 02:14:33] Syncing snapshot 1/555 #2423899 16/25 peers 7 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 2 req/s, 327 µs
[27.08.2017, 02:14:23] Syncing snapshot 1/555 #2423899 17/25 peers 5 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 3 req/s, 186 µs
[27.08.2017, 02:14:13] Syncing snapshot 0/555 #2423899 15/25 peers 5 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 3 req/s, 116 µs
[27.08.2017, 02:14:03] Syncing snapshot 0/555 #2423899 17/25 peers 4 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 3 req/s, 183 µs
[27.08.2017, 02:13:53] Syncing snapshot 0/555 #2423899 15/25 peers 7 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 3 req/s, 283 µs
[27.08.2017, 02:13:43] Syncing snapshot 0/555 #2423899 9/25 peers 4 MiB chain 103 MiB db 0 bytes queue 10 KiB sync RPC: 1 conn, 3 req/s, 6323 µs
[27.08.2017, 02:13:34] Public node URL: enode://df8e086c142326702294d9d7fc152155f16044ed1fcb1924d6b3066223747292dc240af4bb60dac08be32149921ef4f8641519ee77ea321ee3fa66e21cfd1ff5@127.0.0.1:30303
[27.08.2017, 02:13:29] Updated conversion rate to Ξ1 = US$303.92 (391707040 wei/gas)
[27.08.2017, 02:13:28] Configured for Foundation using Ethash engine
[27.08.2017, 02:13:28] Operating mode: passive
[27.08.2017, 02:13:28] State DB configuration: fast
[27.08.2017, 02:13:28] Path to dapps C:\Users\LUCKY\AppData\Roaming\Parity\Ethereum\dapps
[27.08.2017, 02:13:28] DB path C:\Users\LUCKY\AppData\Local\Parity\Ethereum\chains\ethereum\db\906a34e69aec8c0d
[27.08.2017, 02:13:28] Keys path C:\Users\LUCKY\AppData\Roaming\Parity\Ethereum\keys\Foundation
[27.08.2017, 02:13:28] Starting Parity/v1.7.0-beta-5f2
@arkpar I was able to reproduce this on my office laptop today and logged the full trace of sync, network, and snapshot: https://5chdn.co/dump/g7xny97o/8i4h/warp-sync-fail.log.tar.bz2
It's around 65 minutes of logs, warp sync was stuck at 32% and fetching blocks in background.
@arkpar compiled and running. So far it looks good. However, I had to reset my configuration this morning to unregister some tokens. I wasn't able to fix the warp sync until I removed everything in chains/ethereum/*. A db kill command wasn't sufficient. Maybe some old nodes.json? Or some messed up user_defaults?
Here is another user with this issue: https://www.screencast.com/t/bBcU5oYXKm
For some reasons it tries to fetch 700+ snapshots (and eventually fails) while a normal warp sync should only fetch ~360.
There are multiple problems here:
-
When all peers with currently syncing snapshot disconnect sync pauses snapshot sync and falls back to full mode until a snapshot peer appears again. The log still reports snapshot sync as ongoing though. This is fixed in #6560
-
Parity does not preference peers with snapshots, leading to cases when all slots are taken by peers without a snapshot in the middle of an initial sync. This is usually not a problem when syncing after a fresh install because it is likely that the node will be connected to bootnodes that provide snapshots. But this might happen when snapshot sync is starting with an already populated node table, as seen in the log above.
Re: 2) can't we force a default number of "snapshot peers"?
Related / unrelated / offtopic:
I've installed Parity 1.7 some time because of the warp feature.
I'm not sure if 35-37GB is normal... It's less than the full blockchain, but is it still "warpy"? I was actually searching for advice and found this thread... (small internet)
Closed. Restarted. 36.52 GB
Warp sync takes longer because the state of blockchain is bigger.
I wonder will we soon have a WASM client with --warp sync? Will it fit on a mobile browser? And how many seconds for a new user to have a node running? This will be a seriously powerful capability for application developers.
@hynese for mobile devices, you probably want a --light sync.
@arkpar this is addressed, isn't it? I haven't seen any warp issues in a while. @MicahZoltu did you experience any issues with the latest releases?
I haven't tried to warp sync recently. Now that I can avoid triggering #6405 I haven't had a need to re-install Parity.
It would appear this issue has been closed prematurely, as it has only partially been fixed:
As @arkpar explained above:
There are multiple problems here:
When all peers with currently syncing snapshot disconnect sync pauses snapshot sync and falls back to full mode until a snapshot peer appears again. The log still reports snapshot sync as ongoing though. This is fixed in #6560
Parity does not preference peers with snapshots, leading to cases when all slots are taken by peers without a snapshot in the middle of an initial sync. This is usually not a problem when syncing after a fresh install because it is likely that the node will be connected to bootnodes that provide snapshots. But this might happen when snapshot sync is starting with an already populated node table, as seen in the log above.
So, if I'm reading this issue correctly, the first problem has been fixed. But the second issue has not.
I think I'm running into the second issue right now. I'm running 1.8.2 beta, attempting to sync the foundation chain. And my warp sync stopped at around 70%. Now it's reverted to syncing blocks very slowly, and looks like it's going to take days to get synced.
Is there at least a workaround? Is there a way to clear my "already populated node table"?
Gotcha. We should get this fixed before we release 1.9.
In your chains directory is a nodes.json file. Stop your client, remove it, restart Parity.
How do I find chains directory?
Im also having same issue, it warps to a certain block, starts to sync for a while, then goes back into warp and gets suck
Same problem here - 1.8.2 beta on Ubuntu 16.04 - warp sync was interrupted before end - in best case still 200K blocks behind - with speed of regular sync around ~ 3 blocks per sec, it still long time to go. I tried to add more peers - parity --snapshot-peers=25 --max-peers=100 --min-peers=50 maybe it helped a bit but not much.
Regular sync is quite disk IO intensive - so even with SSD it's slow.
Also it looks like warp sync is always starting from zero - there is no way how to restart from some checkpoint?
As per now it's really hard to to sync on regular PC.
Just to add another data point here, I was having this exact problem. I was using warp and it was unbelievably slow, I was probably never going to catch up to the chain.
What solved it for me was deleting the Cache and Chains folders from paritys data directory. After I did that and I restarted parity, I synced an entire snapshot in about 10 minutes.
Also note that parity db kill was not sufficient, I had to manually delete the folders to get parity to stop trying to sync block-by-block and download a new snapshot instead
I started having this issue yesterday, parity got out of sync and didn't manage to get back in sync. Last thing I did now, I noticed I didn't have a config.toml file, is add a config.toml file with just the [parity] section with default values (I have mode=active, not sure that is default). Now it started syncing snapshot, hopefully it will fully sync the snapshot.
I did see a "sync snapshot" yesterday, but it stopped pretty early in the process.
But, unfortunately, after 199/743 syncing snapshot, it's back to normal syncing at block 253,566. I restarted parity about ten times, then finally it managed to do a full snapshot. But then, it started syncing with still about 400k blocks to go. With a speed of less than one block per second, that will still take an awful lot of time.
I was having the same problem today until I changed the port to 30302, then the warp sync seemed to fetch the correct number of snapshots (430) instead of the ~760 it was previously trying to sync.
@xtien @morelazers which version?
@5chdn version Parity/v1.8.2-beta-1b6588c-20171025/x86_64-linux-gnu/rustc1.21.0
Thanks morelazers, I managed to warp sync with the following CLI on Linux 1.9.0-nightly
/usr/bin/parity --port 30302 --no-ancient-blocks --no-serve-light --max-peers 250 --snapshot-peers=25 --min-peers=50 --mode active --db-compaction ssd
Disabling light clients, ancient blocks, changing the network port and deleting the parity database folder seems to have fixed the issue for me. I was able to fully sync 372 snapshots which got me to approx 4315000 block out of 4731424. (91.2%)
Parity would not warp sync without deleting the folder, even though it had only downloaded a few thousand blocks without warp.
EDIT: A pretty poor result, considering the last 10% of the blockchain is where the real grinding starts.
Managed to warp with the settings above to snapshot 640 (~4730000) on 1.8.4 on Win64. Note that simply executing "parity --light db kill" didn't fully clear. It kept trying to sync to snapshot 163 or starting from block 0. I had to remove parity folders from AppData. I believe this separate issue is due to some cache interaction.
Existence of the chain/ directory seems to be key.
I could warp after "rm chains/ cache/ -r". Not very intuitive. I had assumed "parity db kill" should be sufficient to make the next sync be a warp sync.
I had parity 1.7.9 I think, I upgraded to 1.8.2, now it has been syncing for two days, I expect it to finish in another day. I'll just leave it running.
Quick note - you are kind of misreading the initial data on the disk IO. Looking from Linux I see the sync actually reading hundreds of gigabytes of data over and over while writing only some of it (I am seeing sustained 150-200 Mbytes of reads on my SSD, and it is making the rest of the system really unresponsive). What could be the big problem is that the database layer underneath the system is asked to sync every operation to the disc and then re-read the cache for every transaction, which is incredibly wasteful if you will have a couple million transactions coming up right after. IMHO while in catch-up more (while the warning is shown in the UI) the database should be kept in RAM and only synced to disk every 1000 blocks or so. After restarting the sync, I can see 29Gb of data read just after first 10% of (non-warp) sync done and it gets worse later on going to 80Gb read per 10k blocks synced.
(Linux, selfcompiled master at commit ab2caee from Dec 20 22:41:52 2017)
Any progress on this? Any additional information or troubleshooting from us that would help isolate the issue?
I am effectively unable to use Parity at the moment because I can't get it to warp sync and doing a non-warp sync is looking like it is going to take weeks to catch up.
After doing "db kill" and deleting cache and chain folders, the warp sync did work by syncing up to block 4610381. The problem is, however, that after that, the regular sync is super slow. Left it running overnight, in 9 hours it only got to 4669722, disk read of 978Gb, write 2.8Gb. Meanwhile geth managed to do full sync from zero without warp in the same time ...
Log - https://pastebin.com/qAPmHwYK
Hi, I'm trying many days to sync Parity with Foundation chain with no success, in 2 different Ubuntu 16.04 Dell machines. I deleted the chain/ethereum/ and cache/ folders. However it syncs well with Ropsten and Classic chains. I have read many posts about this, and tried many parity command arguments with the same result. It gets stuck on +4.000.000 blocks and syncs very slow after that.
Any advances on this issue?
I also cannot get Parity to sync. Have waited several days now, creeping along slowly at block 4206888, at this rate will never catch up. I have read all of the above, but am not 100% sure of the workaround. Do I delete cache and chains and start fresh? Will that allow me to sync up completely in reasonable time? Or do I have to add extra flags? My version is Parity/v1.9.0-unstable-6bc8866-20171219/x86_64-linux-gnu/rustc1.22.1
So, I jjust tried that, and it warped ahead nicely until snapshot 200/430. Then, it appears to switch to regular synching. Currently, still fast enough, but I fear it will slow down to the same snails pace as before when it reaches those heights. Excerpt of log at end.
From this issue it appears this is happening to everyone trying to catch up to the chain. Any suggestions as to what I can do? Any workaround, no matter how inelegant?
============== . Beginning of log:
2017-12-29 15:04:40 Starting Parity/v1.9.0-unstable-6bc8866-20171219/x86_64-linux-gnu/rustc1.22.1
2017-12-29 15:04:40 Keys path /home/andreas/.local/share/io.parity.ethereum/keys/Foundation
2017-12-29 15:04:40 DB path /home/andreas/.local/share/io.parity.ethereum/chains/ethereum/db/906a34e69aec8c0d
2017-12-29 15:04:40 Path to dapps /home/andreas/.local/share/io.parity.ethereum/dapps
2017-12-29 15:04:40 State DB configuration: fast
2017-12-29 15:04:40 Operating mode: active
2017-12-29 15:04:40 Configured for Foundation using Ethash engine
2017-12-29 15:04:40 Updated conversion rate to Ξ1 = US$748.73 (158999400 wei/gas)
2017-12-29 15:04:47 Public node URL: enode://57f94b870578e3dbe97b19deabb67acab9336b7c292871d1d0e8cc57370e2ee4665501f1d7218467c44c6c3eaae915260e0863fc5e2b0b367e6d033fa2153b2f@192.168.0.110:30303
2017-12-29 15:04:52 Syncing snapshot 0/430 #0 11/25 peers 8 KiB chain 3 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 15:04:57 Syncing snapshot 1/430 #0 13/25 peers 8 KiB chain 3 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 15:05:02 Syncing snapshot 3/430 #0 16/25 peers 8 KiB chain 3 MiB db 0 bytes queue 10 KiB sync RPC: 0 conn, 0 req/s, 0 µs
==============Place where it stops warping:
2017-12-29 15:20:52 Syncing snapshot 198/430 #0 49/50 peers 8 KiB chain 3 MiB db 0 bytes queue 19 KiB sync RPC: 1 conn, 4 req/s, 47 µs
2017-12-29 15:20:57 Syncing snapshot 199/430 #0 50/50 peers 8 KiB chain 3 MiB db 0 bytes queue 19 KiB sync RPC: 1 conn, 0 req/s, 44 µs
2017-12-29 15:21:02 Syncing snapshot 200/430 #0 50/50 peers 8 KiB chain 3 MiB db 0 bytes queue 19 KiB sync RPC: 1 conn, 4 req/s, 44 µs
2017-12-29 15:21:07 Syncing snapshot 200/430 #0 50/50 peers 8 KiB chain 3 MiB db 0 bytes queue 19 KiB sync RPC: 1 conn, 1 req/s, 44 µs
2017-12-29 15:21:12 Syncing #0 d4e5…8fa3 0 blk/s 0 tx/s 0 Mgas/s 123+ 0 Qed #127 47/50 peers 8 KiB chain 3 MiB db 234 KiB queue 1 MiB sync RPC: 1 conn, 5 req/s, 44 µs
2017-12-29 15:21:15 Imported #127 707c…91ed (0 txs, 0.00 Mgas, 1.57 ms, 0.53 KiB) + another 1 block(s) containing 0 tx(s)
2017-12-29 15:21:28 Imported #128 53d6…05d4 (0 txs, 0.00 Mgas, 0.39 ms, 0.53 KiB)
2017-12-29 15:21:30 Imported #381 88ad…dd0a (0 txs, 0.00 Mgas, 8.81 ms, 1.06 KiB) + another 4 block(s) containing 0 tx(s)
2017-12-29 15:21:32 Imported #382 d33a…6e26 (0 txs, 0.00 Mgas, 1.07 ms, 0.53 KiB)
2017-12-29 15:21:37 Syncing #382 d33a…6e26 0 blk/s 0 tx/s 0 Mgas/s 0+ 0 Qed #382 46/50 peers 416 KiB chain 5 MiB db 0 bytes queue 6 MiB sync RPC: 1 conn, 10 req/s, 38 µs
2017-12-29 15:21:47 Syncing #382 d33a…6e26 0 blk/s 0 tx/s 0 Mgas/s 0+ 0 Qed #382 49/50 peers 416 KiB chain 5 MiB db 0 bytes queue 6 MiB sync RPC: 1 conn, 7 req/s, 38 µs
2017-12-29 15:21:52 Syncing #835 abc0…f56b 90 blk/s 0 tx/s 0 Mgas/s 51+ 1 Qed #890 47/50 peers 894 KiB chain 9 MiB db 102 KiB queue 11 MiB sync RPC: 1 conn, 14 req/s, 60 µs
2017-12-29 15:21:58 Syncing #1205 ef87…1ee0 73 blk/s 0 tx/s 0 Mgas/s 3193+ 0 Qed #8257 47/50 peers 1 MiB chain 10 MiB db 6 MiB queue 12 MiB sync RPC: 1 conn, 12 req/s, 183 µs
The GUI says "47.21% warp restore", which appears to be a lie. It is also not advancing, even though the sync is, per the log.
I have managed to sync 2 nodes on AWS EC2 m4.xlarge instance (I used m4.xlarge for the network performance, switched back to t2.medium after synced).
The parameters I used: parity --cache-size 1024 --db-compaction ssd --jsonrpc-hosts all --jsonrpc-interface all --snapshot-peers=25 --max-peers=100 --min-peers=50
(strangely, if I set --cache-size to something larger, the Syncing snapshot is not triggered)
After the log showed Syncing snapshot a while, it went back to Syncing #<blockNumber> and I left it for a little while, hit Ctrl-C and run the command again. If it showed Syncing #<blockNumber> again, I left it for a while, hit Ctrl-C and repeat. Somehow, it's back to Syncing snapshot.
Repeating this 2 or 3 times and my nodes are synced.
I have been having this issue for a while. Tried the above solutions, e.g. db kill + cache/chain deletion, but the synchronisations keep getting stuck. Not sure if it's coincidence but each time, the stuck block is "4,xxx,001". The first time it was stuck at 4,300,001. Another time it was 4,4??,001. And now it stops at 4,370,001.
Parity version is "Parity/v1.8.0-unstable-684b14271-20170921/x86_64-macos/rustc1.19.0"
I tried --light, but that did not work, either. It went synching really fast for a while, then suddenly stopped:
2017-12-29 18:48:52 Syncing #1169644 972c…38ba 370 hdr/s 12835+ 0 Qed #1169644 27/50 peers 10 MiB cache 11 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:48:57 Syncing #1170812 f603…1f29 233 hdr/s 11666+ 0 Qed #1170812 27/50 peers 10 MiB cache 10 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:02 Syncing #1172567 f42e…90b1 350 hdr/s 9912+ 0 Qed #1172567 27/50 peers 10 MiB cache 8 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:07 Syncing #1174506 600e…e254 387 hdr/s 7972+ 0 Qed #1174506 28/50 peers 10 MiB cache 7 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:12 Syncing #1176421 39f4…9b73 383 hdr/s 6058+ 0 Qed #1176421 28/50 peers 10 MiB cache 5 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:22 Syncing #1180283 3ba6…aa64 386 hdr/s 2194+ 0 Qed #1180283 29/50 peers 10 MiB cache 2 MiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:27 Syncing #1182268 3905…09bb 397 hdr/s 206+ 2 Qed #1182268 29/50 peers 10 MiB cache 185 KiB queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:32 Syncing #1182482 6980…9c65 42 hdr/s 0+ 0 Qed #1182482 30/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:37 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 31/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:42 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 33/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:47 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 34/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:52 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 34/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:49:57 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 34/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2017-12-29 18:50:02 Syncing #1182482 6980…9c65 0 hdr/s 0+ 0 Qed #1182482 34/50 peers 10 MiB cache 0 bytes queue RPC: 0 conn, 0 req/s, 0 µs
2
.... continues forever at #1182482
Tried to run overnight with parameters suggested by implicit-invocation, above. Warped for maybe 200 snapshots, up to some early block number, then started syncing regularly at 100-200 blk/s. This morning, was around block 2,700,000, but slowed to a crawl at 1-2 blk/s. Until someone fixes this or posts a workaround, parity no longer works for me. I'll see if I have less problems with geth.
Did this with updated version Parity/v1.9.0-unstable-2586eae-20171229/x86_64-linux-gnu/rustc1.22.1, compiled from master branch on Ubuntu, git commit 2586eae
Just FYI: I went back and tried geth, because I needed to get some ether sent right now. Geth managed to sync the chain in roughly 8 hours and I am moving on. Will monitor here, though, and after there is a fix give it another go. Sorry I can't help other than by reporting my experience....
It's quite interesting that there seems to be no response to this ticket, because it literally prevents anyone new from syncing Parity.
The only workaround that actually works is - since majority of the work is slow because of crazy I/O (as snapshots don't really work right now), if you have a 64GB/128GB RAM machine, you can either put the parity chain+cache folder on a ramdisk, or you can launch parity with a ridiculously large --cache-size parameter. I was able to achieve a full sync in a few hours using a ramdisk, even without snapshots.
Not sure if this is useful, but attempting to warp with 1.8.5 beta --cache-size 1024 --snapshot-peers=25 gave me a Corruption: block checksum mismatch error :
https://gist.github.com/danuker/a759df6eaa420f9c695db88e153bdce7
Another attempt, this time apparently just giving up warping:
https://gist.github.com/danuker/beb599acdcf42a06440900f285641a8d
Looks like they stopped warping after ~45 minutes.
Please remove your [...]/chains/ethereum/network/nodes.json and upgrade to 1.8.6. This should be resolved. Follow-up issue is #7436 relevant in the near future.
Did you delete my relay and "summarized" it in yours? O_o Seriously?
Did you delete my relay and "summarized" it in yours? O_o Seriously?
Could you rephrase that question?
My apologies. I think I overworked. I checked in the wrong issue. Feel free to delete my latest posts post in this thread
How is it that this is closed?
C:\Users\david_000>parity --version
Parity
version Parity/v1.8.6-beta-2d051e4-20180109/x86_64-windows-msvc/rustc1.22.1
Copyright 2015, 2016, 2017 Parity Technologies (UK) Ltd
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
By Wood/Paronyan/Kotewicz/Drwięga/Volf
Habermeier/Czaban/Greeff/Gotchac/Redmann
Sometimes it will sync snapshots, sometimes it will not.
It appears to be completely random and Parity under my invocation(s) doesn't appear to get enough information to figure out why it is doing what it is doing. Given sufficient time, I think I could base a cryptographically secure 2-headed coin toss based on the question, "Will it try to sync via warp on this invocation after 5 minutes?".
HOW would I have Parity state things like:
- Today I am syncing block by block because I cannot find a peer to warp sync with
- Today I am warp syncing
- I cannot warp sync today even though I know there are snapshots available because something happened yesterday and I can't, investigate the logs at...
The tool's complete lack of transparency as to why it can't sync is entirely frustrating.
How is it that this is closed?
Warp-sync is hardly salvageable. I'm sorry.
The key issue is #7436 that prevents most nodes from generating snapshots, but even we could fix this temporarily, it will be only an intermediary duct-tape solution until the state is too big again.
With 1.8.6 I can recommend resetting the DB and trying a full sync, and for the long-term (1.10+) will stabilize the light client experience for different use-cases.
Ubuntu 16.04, Parity 1.8.11
Step 1 - is important
$ parity db kill --chain=foundation
Step 2
$ parity --warp --no-ancient-blocks --no-serve-light --max-peers 250 --snapshot-peers 50 --min-peers 50 --mode active --tracing off --pruning fast --db-compaction ssd --cache-size 4096
Result: ~40 min 5173638 blocks
So is this a "not to fix"? If so, does that mean that parity is being retired -- this is a show stopper for anyone looking to setup a new node. I have been trying for almost 4 days and have resulted to now try the "no warp" sync which looks like it may take another 4 days. If so, that is going to be pretty much useless in terms of bringing new nodes online.
With warp-sync no longer working and the light client not ready yet, Parity is completely unusable for me and, I guess, for anyone who can't afford to sync the full blockchain.
The suggested workaround of killing the db does the trick, but has to be redone every time I open Parity so it's also unfeasible.
If warp mode can't be fixed, can it at least any mention to it be removed from end-user documentation, so people don't waste their time trying it?
@ravensorb The issues have been identified and split into sub-tasks, you can find an overview here: https://wiki.parity.io/Known-Issues-Priorities
@codewiz Warp-sync is not broken per se, and it works very well for any other chain than Ethereum. The current state size for Ethereum is a serious problem, and this is not a Parity issue in first place.
@ravensorb we will definitely attempt to fix it, this is a duplicate. See the list of known issues, this is the 1.3
Anyone looking to setup a new node should be either interested in having the whole DB locally to query it heavily, the need for a full node is implicit. These user will have to wait for a full sync, this is clear. Anyone looking for a wallet and sign transaction now and then will be ok with a light node synced in a couple of seconds, minutes.
@codewiz Did you try the light client ? If you can't afford to sync the chain, then you can't afford a full node and --light is what you are looking for.
I tried light client 1.9.5-stable. Unfortunately it took 5 hours to get synced. Database size is just 2.5 Mb, but downloading speed is extremely slow.
Also if it helps, I think the warp sync issue also occurs when parity maxes out the IO of the storage system (its not just low memory)
@melnikaite 5 hours is incredibly fast for verifying 5.3 million block headers :)
@ravensorb to get a full parity DB synchronized, just leave your client running overnight. ideally, on a machine with SSD.
@5chdn Is it possible to disable verifying?
@melnikaite yes #8075 - in 1.11:
After this change, the light client synchronizes in 10 to 15 seconds even at the first launch on the main network.
@5chdn I was afraid of that :) I am now going on 23 hours using the nightly docker image (pulled just before I started the sync) and it is stuck at 90.90%
I'll give it another few hours and than if it doesn't make any progress, I'll kill it, clear the db, and try again.
No need to kill the DB, just leave it running, otherwise it will start from scratch again
@5chdn I noticed :) It seems to take about 2 hours to get to block 4880040 and then it drops to syncing a block every 2 seconds. If my math is right, that means I am looking at almost 10 days to complete the last 446k blocks. Does that sound correct??
Looks about right
@5chdn all I can say is WOW. If your curious, in the past 48 hours its only progressed 1%. Are there any options to speed this up?
If it helps, here is the command I am using to launch the docker container
docker run -ti --name parity-nightly --restart unless-stopped --net=bridge -v /opt/parity/nightly:/opt/parity -p 8180:8180 -p 8545:8545 -p 8546:8546 -p 30303:30303 -p 30303:30303/udp parity/parity:nightly --ui-interface all --jsonrpc-interface all --jsonrpc-apis all --jsonrpc-hosts all --ui-hosts=all --ws-interface all --ui-no-validation --config
/opt/parity/config.toml --no-ancient-blocks --no-serve-light --max-peers 250 --snapshot-peers 50 --min-peers 50 --mode active --pruning fast --cache-size 4096
Increase the --cache-size as much as possible and get a decent SSD :)
@5chdn What --cache-size do you prefer?
My favorite cache size is 12288 :)
My favorite cache size is 31337
this problem is clearly still occurring, but I've noticed that when it drops out of warp mode into normal syncing, I usually get the error:
"encountered error during state restoration. chunk size is too large"
I hope this log will be useful for investigating this issue https://pastebin.com/YN8sUs2t
Hay!!! I suffered an accident. Out of hospital