Closed jcnelson closed 1 month ago
I've observed something on a signer node that might be related. Noting here for tracking, happy to move to a new issue if that's more appropriate. Note that I've already sought input and debugging help from @hstove and @jferrant on this.
The setup:
stacker = true
I'm running the binaries directly, co-located on the same machine. There's also a dedicated bitcoind. This setup has been running for several months at this point, without any problems.
Symptoms:
/v2/neighbor
reports plenty of nodes with non-empty stackerdb entries. I can include a full output if that helps.I think I know the reason for this now. The network pruner starts removing new connections after 10 outbound peers have been found (this is the default limit). Network subsystems have a way of "pinning" connections so they won't get pruned while they're in use, but there was a bug in the way the pinning system worked which had a very immediate and noticeable impact on StackerDB (especially since a signer or miner would be running a couple dozen replicas). I'll have a patch out soon, once I'm done testing it.
Based on the draft PR, would a workaround be to increase soft_max_neighbors_per_org
-- happy to test that out if that helps.
closing since #5197 is merged
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
For reasons that are not yet clear, Nakamoto testnet and mainnet StackerDB replicas will eventually lose coherence. Writes to one replica do not find their way to others -- neither via push, nor via sync. This needs investigation, and may be partially fixed by #5191.