Ord 0.21.0 very slow to index #3999
Comments
|
This is likely caused by the fractal ord server I am running on the same server. Fractal sees frequent reorgs which triggers a lot of disk I/O to restore from the snapshot. I'll shut down the fractal ord server and see if that fixes the problem. |
|
I was also running a couple scratch indexes on 0.21.0. (1 was sats/runes/addresses and the other was runes/addresses.) After running overnight, this morning both of them were stopped while committing at block 350000. I watched them both stay there for a couple hours, then pressed ctrl-c and watched them attempt to stop for a couple hours before killing them. Seems like something's up here! |
No fractal running on mine, although I did just update Bitcoin core to v28. |
|
I got past 350000 by setting commit-interval to 10. currently near 412000. This is an index build from scratch - with-address/runes |
|
I enabled logging and restarted from scratch again, with the default commit interval. I'm in the 300000s now and it's starting to get pretty slow committing to disk. My sats/runes/addresses run has been working on committing at 305000 for over 30 mins now. |
I restarted from scratch again, this time with |
|
this may be related to #3804 |
Perhaps it's related but it's new set of symptoms, for me anyway. My system that has been able to crank out a runes/addresses index in 12 hours on 0.20.0 with default 5000 commit interval was stuck at block 350000 overnight on 0.21.0, and even with commit-interval 20 is taking way too long. I'm coming up on a full day and I'm only to block 640000 or so for a runes/addresses/no-sats index. |
|
We didn't change any indexing logic from |
|
I get the same noticeable slowness tooSent via the Samsung Galaxy Note20 Ultra 5G, an AT&T 5G smartphone
-------- Original message --------From: raph ***@***.***> Date: 10/16/24 15:00 (GMT-08:00) To: ordinals/ord ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [ordinals/ord] Ord 0.21.0 very slow to index (Issue #3999)
We didn't change any indexing logic from 0.20.1 to 0.21.0 so this is weird. Let me try to reindex on our dev server as well.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
The change was likely done before as nobody re-indexed when 0.20.1 was release because the DB schema version wasn't bumped Suggestion: setup a nightly representative performance test and plot the results. Take a look for e.g. at https://github.com/sharkdp/hyperfine |
I actually did reindex with 0.20.1 due to the issue with address indexes crashing, and I didn't see this performance issue in that version. |
Did you do a |
No, just addresses/runes. Same as I'm doing on 21, which has been running for days now. (Used to finish in ~12 hours.) |
|
I think I've pinned it down to a regression in redb from version This version update was done in this commit if you have a look at |
|
#4003 appears to have fixed this. Here are some logs showing how the problem happened in 0.21.0 and is resolved again now. The commits around block heights in the 300k's usually take about 2 minutes but around block 380k they really slow down with redb 2.1.4: 0.20.0 (redb 2.1.3): 0.21.0 (redb 2.1.4): origin/master (redb 2.1.3): |
|
Here's the same but without 0.20.0 (redb 2.1.3) - 8 to 10 minutes per commit: 0.21.0 (redb 2.1.4) - 3 minutes to 19 hours per commit: origin/master (redb 2.1.3) - 3 to 4 minutes per commit: |
I am building a pair of ord 0.21.0 indexes:
Note the 'no sats' index started doing a commit at 10:30pm yesterday and now it's 2:40pm. That's over 16 hours for a commit. I've not seen a commit take more than 2 hours before.
The index files are both currently 25G:
The text was updated successfully, but these errors were encountered: