-
Notifications
You must be signed in to change notification settings - Fork 679
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
Strange behaviour with event_observer blocking node sync #5663
Milestone
Comments
this happened again actually, so i'm not 100% certain it's due to the http requests:
i can't be sure anymore this isn't an API issue either |
this specific issue may be related to this change in the API we're testing after the recent stall i encounterd above: hirosystems/stacks-blockchain-api#2217 |
this seems to be resolved in API v8.6.0. closing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Infra setup is like this:
VM:
4vcpu
8GB memory
500GB disk
stacks-core running with a more or less default config with the following event_observer block:
stacks-core and the API are both running in docker via docker-compose, with an externally hosted DB that the API is writing to.
Both services are on the latest released versions.
Until recently (roughly 1 week ago - around dec 26th, 2024) , this setup was able to stay at chain tip reliably. around that day, i noticed it was falling behind, and the logs weren't much help in determining why.
on the API logs:
Skipping mempool stats query because CONNECTION_DESTROYED
was interesting, but it seems to be a normal logged event in the API.on the stacks-core side, the node was scrolling logs like this:
system resources for the VM were all really low - no memory/load pressure and the IO usage was surprisingly low (probably due to not syncing new blocks).
restarting the services (api and stacks-core) resolved the issue, but only for about an hour or so after each restart before the mempool HTTP requests came flooding back.
the only thing that helped here was to disable ingress on 20443 (i also disabled 20444) - once those ports were firewalled, the node has stayed at chaintip without further issue.
I'm not sure if this is a bug, but i think it's interesting enough to open an issue.
Logs attached when this surfaced after a restart
exported-logs.tar.gz
The text was updated successfully, but these errors were encountered: