[Filebeat] aws-s3 - create beat.Client for each SQS worker#33658
[Filebeat] aws-s3 - create beat.Client for each SQS worker#33658andrewkroh merged 3 commits intoelastic:mainfrom
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.asciidocorCHANGELOG-developer.next.asciidoc.Related
Pprof Mutex
I ran Filebeat for 90s with
max_number_of_messages: 5.Before
After