cumulus icon indicating copy to clipboard operation
cumulus copied to clipboard

Parachain finalization keeps import lock occupied after sync

Open skunert opened this issue 2 years ago • 0 comments

I was investigating some issues I saw when syncing a parachain full-node.

Log excerpt:

2023-04-26 22:25:25.164 DEBUG ⋮cumulus-consensus: [Parachain] Attempting to finalize header. block_hash=0x2aed5dcdfd9c6bae1f1a0e66f2148f6e916e6960b51a92ed04aae92d01e2d7a5
...
2023-04-26 22:25:25.198 TRACE ⋮sync::import-queue: [Parachain] Starting import of 1 blocks  (4364184)    
2023-04-26 22:25:25.198 TRACE ⋮sync::import-queue: [Parachain] Header 0x4c29…834f has 2 logs  
...  
2023-04-26 22:26:17.696  INFO ⋮substrate: [Parachain] ⚙️  Preparing  0.0 bps, target=#4364188 (8 peers), best: #4364182 (0xce70…627c), finalized #0 (0x4823…771a), ⬇ 10.5kiB/s ⬆ 3.2kiB/s    

The node is using an external RPC for the relay chain. This means we immediately get finality notifications from the tip of the relay chain. At some point the parachain reaches the tip of the chain and suddenly finalizes millions of blocks. This occupies the import lock for ~10min on a rather weak cloud machine and ~1.5min on my local machine, effectively blocking all import operations.

Overall I think this is working as expected, but maybe we can find a way to improve the situation a bit. Found this as part of investigation for https://github.com/paritytech/polkadot-sdk/issues/13, which seems to be unrelated after all (since the relay chain is also importing slowly in that issue and logs show parachain finality).

skunert avatar Apr 28 '23 10:04 skunert