Skip to content
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

ld: Use htable to detect own transactions #5715

Merged
merged 3 commits into from
Nov 18, 2022

Conversation

cdecker
Copy link
Member

@cdecker cdecker commented Nov 15, 2022

@whitslack did an in-depth analysis of the issue at hand, and it turns out we were doing quadratic lookups on an ever increasing list of transactions we broadcast, with ever rebroadcast doubling the size of the rebroadcast list.

The first commit avoids adding the same TX multiple times, while the following two commit replace the entire list with an htable instead, reducing complexity to linear.

Fixes #5682

The list of outgoing transactions was growing with every
rebroadcast. Now we just check whether it is already in the list and
don't add it anymore

Changelog-Fixed: ld: Reduce identification of own transactions to not slow down over time, reducing block processing time

Suggested-by: Matt Whitlock <@whitslack>
We were using a quadratic lookup to locate the transactions we
broadcast, so let's use an `htable` instead, allowing for constant
lookups during block processing.
We had a quadratic check when processing a block, and this just
reduces it to be linear. Combined with the previous fix of adding txs
multiple times, this should speed up block processing considerably.
@cdecker
Copy link
Member Author

cdecker commented Nov 16, 2022

This is a rather simple PR, however there is one issue that I could not fix on the fly:

https://github.com/ElementsProject/lightning/pull/5715/files#diff-f13ab0f51e9574e49798cd32c0cf2a2476bc1dbd01d1aa31eb4ff9c1d6df6d94R218

Notice the notleak here to avoid shutdowns falsely detecting leaked outgoing_tx instances, which I don't quite get where these are from. The loop in the destructor should ensure we free all the queued instances, but it seems not to quite get them all. Could this be a concurrent modification of the htable (via the destructor added to outgoing_tx instances)?

@whitslack
Copy link
Collaborator

Could this be a concurrent modification of the htable (via the destructor added to outgoing_tx instances)?

Hmm, but you're removing the destructor before freeing each outgoing_tx in the map. Assuming that's working correctly, there shouldn't be any concurrent modification of the htable during the iteration over it.

@cdecker
Copy link
Member Author

cdecker commented Nov 18, 2022

Yep, that was an attempt to avoid this issue, but it didn't work, which is why I'm asking here :-)

@cdecker cdecker added this to the v22.11 milestone Nov 18, 2022
@cdecker cdecker merged commit d27591f into ElementsProject:master Nov 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Long periods of unresponsiveness every time a block is added
2 participants