Cherry-pick #19764 to 7.8: [Auditbeat] Fix up socket dataset runaway CPU usage #19781
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of PR #19764 to 7.8 branch. Original message:
What does this PR do?
Fix for auditbeat runaway CPU usage: #19141
So, here's the explanation, basically everything was pretty much as described in the previous PR (#19033), the only additional things that I found were that:
*socket
is terminated by another socket with a different kerneltid
it's moved to theclosing
LRU list.*socket
is added to the statesocks
map with the ptr reference pointing to itonSockTerminated
is called againonSockTerminated
the socket is pruned again from thesocks
map with the call todelete(s.socks, sock.sock)
socks
map now refers to the new*socket
rather than the old one*socket
times outonSockDestroyed
is called on it with the code that's doing the peek on thesocketLRU
in the reaper codesocks
map in step 5onSockDestroyed
was running the following code:found
was returningfalse
and the function was returnings.socketLRU.peek()
the same socket was getting returned over and over, resulting in the reaper routine getting wedged in a tightfor
loop (hence the high CPU usage).The fix
Basically we pass a reference to the
*socket
object in the reaper'sonSockDestroyed
call, that way we don't have to look up the socket ins.socks
and, instead handle the socket closure directly.Related issues