-
Notifications
You must be signed in to change notification settings - Fork 116
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
Fix PeerManager mutex bottleneck #875
base: main
Are you sure you want to change the base?
Conversation
7c0ca2e
to
f9be3f2
Compare
8bb481e
to
7b97171
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a way to quantify performance gains of linearizing the execution using chanqueue
?
Do not try to acquire a MessageQueue mutex while holding the PeerManager mutex. A MessageQueue mutex may already be held for message processing and waiting for these will delay releasing the global PeerManager mutex. Instead, start goroutines to update the MessageQueue asynchronously so that the PeerManager lock can be released sooner.
7b97171
to
bc94cda
Compare
Watch staging metrics for now. There is not any "linearizing the execution" since the code passed to the chanqueue was already serialized by the MessageQueue My bigger concern is that now there are 2 more goroutines per peer, so if this does not reduce waiting goroutines then it actually can make things worse. |
Do not try to acquire a MessageQueue mutex while holding the PeerManager mutex. A MessageQueue mutex may already be held for message processing and waiting for these will delay releasing the global PeerManager mutex. Instead, enqueue calls to MessageQueue and let an asynchronous goroutine execute the calls so that the PeerManager lock can be released sooner, without having to wait for the MessageQueue operations.
In short, this decouples the PeerManager from the per-peer MessageQueue mutexes.
Kubo PR: ipfs/kubo#10749