-
Notifications
You must be signed in to change notification settings - Fork 224
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
Reduce allocs in ReadMessage (unix transport) #347
Conversation
9625d0b
to
610d8b4
Compare
Context cancelled, server emitted 2670 signals. panic: read unix @->/run/user/1001/bus
610d8b4
to
cc6e0c0
Compare
35cb2ef
to
925ecbb
Compare
I figured out why there was an extra memory consumption per operation after refactoring and resolved the problem.
|
925ecbb
to
a8c1d8f
Compare
Down to 606 allocs from 907, also the benchmark shows 8.17KB less memory usage.
|
I will try these changes on some realistic workload to make sure there is no regression. |
I have tested the changes on Parca Agent and posted memory profiles here parca-dev/parca-agent#1037 (comment). |
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.
Thanks for the work and detailed stats!
It appeared to me that certain decoding performed in
ReadMessage
was repeated inDecodeMessageWithFDs
, so I got rid of it. That yielded 58 less allocs, though consumed 5.63KB more per operation according to the benchmark.It seems more memory is spent at
syscall.anyToSockaddr
after refactoring, see the profiles below.new
old