Index progress commit taking 20+min

[jorge-j1m]

Running v0.5.1, indexing with --index-sats.

(See 20min difference between starting to commit the index and resuming syncing)

I fail to understand what is the purpose of committing to the local file mid sync, if the process is killed suddenly the index is corrupted, not usable anymore (there isn't, to my knowledge, any way to salvage a corrupt index, --index-sats enabled or not), and when it receives a SIGINT it commits the process anyway, again taking 20+mins. During this time the disk usage skyrockets (I'm running it locally on nvme storage, disk speed is not the issue), writing tens of GB of data, but the index file does not increase its size so I'm having issues making sense of it.

[lepar]

Having the same issue, took mine 31 minutes. Running on 8gb ram/Ryzen 7 4800h/1tb HDD (not ssd, maybe that's the bottle neck)

I've been syncing for 48 hours with --index-sats and it's still at block 571k

2023-02-26T11:09:16Z INFO ord::index::updater] Wrote 1355807 sat ranges from 6036 outputs in 401 ms [2023-02-26T11:09:16Z INFO ord::index::updater] Committing at block height 571066, 27528498 outputs traversed, 6666306 in map, 20862192 cached [2023-02-26T11:09:16Z INFO ord::index::updater] Flushing 6666306 entries (24.2% resulting from 27528498 insertions) from memory to database

[2023-02-26T11:40:43Z INFO ord::index::updater] Block 571066 at 2019-04-10 18:30:37 UTC with 2588 transactions… [2023-02-26T11:40:43Z WARN ord::index::updater] failed to fetch block 571099, retrying in 2s: JSON-RPC error: transport error: HTTP response too short: length 0, needed 12. [2023-02-26T11:40:48Z INFO ord::index::updater] Wrote 421869 sat ranges from 5375 outputs in 5098 ms