-
-
Notifications
You must be signed in to change notification settings - Fork 26
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
Most recent node tip of Kupo may get stuck #143
Comments
Hey,
Some of your connections have an extremely high number of failed attempts. Which is rather odd. Some are even just failing to open (250ms is the retry delay on open). It might be necessary to ALSO prune binary_data incrementally (incremental deletion only happen for rollbacks and inputs pruning so far) to avoid keeping the database busy for too long. The high |
We've noticed a similar issue on Kupo v2.7.0 where garbage collection on Arguments:
|
Here's the debug logging excluding health checks (via |
Thanks a lot @Saghen; I am a bit overloaded lately but I will look into it by next week the latest. One last question, I take from the command above that you aren't running with a special gc-interval, but using the default one? |
Sounds good! And yep, using the default interval |
Reporting that kupo mainnet still is choking on the pruning (limited to 50k rows now, ~approx since 20 minutes). Would it make sense to make the pruning increment size a command line option?
|
I am surprised however by the time you're reporting. I've tested this on a dev machine which took less than 30s per batch, with 1.5M entries to delete. What are the specs of the machine you're running this by? |
We're seeing similar behavior as Niels; Garbage collection took 15 minutes and stalled the syncing. We're running with 2 cores, 2GBs RAM and NVME. |
As identified in another discussion, Kupo is missing one crucial database index somehow. This got probably lost in some refactoring and failed to be caught by tests. So right now, you may want to run (offline):
This should take a minute or so, and solve the GC issue for now. A single GC increment should take no more than a minute. And given that you probably have a lot of data to clean up from previously interrupted GC, it'll take several minutes / hours to clear everything down. Though synchronization should be interleaved without problem. |
Nothing extra is needed since 2.7.2, the issue was fixed. |
What Git revision / release tag are you using?
2.7.0+41ae67
Describe what the problem is?
Same as #142
It is unfortunately not resolved by upgrading to kupo 2.7.0
What should be the expected behavior?
The most recent node tip should always refer to the actual most recent node tip.
If applicable, what are the logs from the server around the occurence of the problem?
The respective log from kupo
The current time when fetching this log and seeing the tip difference was 12:15 UTC
The text was updated successfully, but these errors were encountered: