-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Filebeat] aws-s3 - create beat.Client for each SQS worker #33658
[Filebeat] aws-s3 - create beat.Client for each SQS worker #33658
Conversation
53cb8c3
to
f231b1e
Compare
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
To address mutex connection in the single beat.Client used for publishing S3 events, create a unique beat.Client for each worker goroutine that is processing an SQS message. The beat.Client is used for all S3 objects contained within the SQS message (they are processed serially). After all events are ACKed the beat.Client is closed.
f231b1e
to
ae78fa0
Compare
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
/test |
I'm wondering if beats/libbeat/publisher/pipeline/client.go Lines 72 to 77 in 3e928b7
If it's guaranteed that X can't panic, then it can be rewritted as
which will reduce the time during the locked state. If that can't be guaranteed, then this makes some (less) reduction without the potential for leaving the mutex in the locked state, by retaining the deferred unlock, but not locking until the defer is constructed.
|
I remember back in Go 1.14 the release notes came out saying that It is possible that a processor could panic so I would be wary of removing the
Interesting, I've never seen code that uses this ordering. I realize that it has the same outcome. What makes this any different? |
This comment was marked as outdated.
This comment was marked as outdated.
…-reader-beat-client
The time taken is the same, but less of that time is in the locked state. |
…-reader-beat-client
To address mutex connection in the single beat.Client used for publishing S3 events, create a unique beat.Client for each worker goroutine that is processing an SQS message. The beat.Client is used for all S3 objects contained within the SQS message (they are processed serially). After all events are ACKed the beat.Client is closed.
What does this PR do?
To address mutex contention in the single beat.Client used for publishing S3 events, create a unique beat.Client for each worker goroutine that is processing an SQS message. The beat.Client is used for all S3 objects contained within the SQS message (they are processed serially). After all events are ACKed the beat.Client is closed.
Why is it important?
A mutex profile of the aws-s3 input showed that there was a lot of contention for the "Publish()" lock.
beats/libbeat/publisher/pipeline/client.go
Lines 72 to 77 in 3e928b7
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related
Pprof Mutex
I ran Filebeat for 90s with
max_number_of_messages: 5
.Before
After