-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ord indexing "loops" or "resets" back to a previous level and never completes #3804
Comments
Thanks for reporting this, so7ow. I've been experiencing it for sometime and can confirm that a large swath of Ordicord users experience it as well. I'm not sure the best way to handle it, but my initial thought is to just drastically lower the default commit interval (which is currently at 5000). My machine has 32GB of RAM and I've had to lower the interval to single digits at times. Perhaps if this setting was changed to be based on GB of RAM rather than number of blocks? |
I have encountered the same problem as well. |
Yup, I'm having the same issue myself. I've spent a few days trying to resolve it with no success. The reporting of any fix or workaround would certainly be appreciated. |
The workaround that seems to resolve the issue for everyone is to set the |
Been experiencing this issue for the past 3 weeks. I’ve attempted the —commit-interval flag with different amounts and it still loops. Only way I can successfully index right now is to let it run and then ctrl c to safely shutdown and it registers. It’s just very time consuming doing this and wish I could just let it run like normal 😅 Windows 64GB Ram plenty of storage. |
How low a value for commit interval did you try? |
Went as low as 25 |
Go lower. 👍🏻 |
Yeah, it finally worked for me at 5. |
@raphjaph I think we could use the expertise of mconst on the fix for this issue. It should be easy enough just to lower the default value for the It seems like it could be a zero-sum change. For example, an index with a default commit interval might spend 5 minutes every 5000 blocks updating the db with those blocks, but lowering that value to 100 could take the same time if the server then only spent 6s per update. If that were the case, the lower value wouldn't impact overall indexing time. I'm just not sure that is the way it works. |
I wanted to follow up and say 5 worked for me. Thank you! |
Is this specific to Windows, or does it affect other OSes? |
Windows here, not sure about the others. I'll start asking everyone in the Ordicord that experiences this issue from now on. |
@cryptoni9n Thanks! @partialord is a little worried that a future performance improvement might exacerbate this issue, so we want to make sure it's nailed down. Any additional information is super useful. |
Other things which would be good to know when someone runs into this bug:
|
On the Ordicord we've seen many reports of issues since the halving, where ord indexing loops indefinitely, returning to previous levels and never completing successfully. We've been recommending folks add a
--commit-interval 100
(or even lower value sometimes) and that generally seems to fix it. Rather than just continue doing that forever, I wanted to bring it up here, and see if any of the devs are aware of the situation and/or working toward a fix. Or maybe our workaround is enough? Don't know, seems like there should be some way to adapt that commit interval when the machine it's running on is struggling.Low RAM seems to be a factor, but, to be clear, this issue has not affected me directly so I don't have any specifics to report, just generalities!
The text was updated successfully, but these errors were encountered: