Re-factor to fix high CPU usage on windows #1562
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Don't merge yet, please, I need to test if it all looks good under Windows. |
| @@ -115,7 +115,10 @@ func (t *Topbeat) Setup(b *beat.Beat) error { | |||
| func (t *Topbeat) Run(b *beat.Beat) error { | |||
| var err error | |||
|
|
|||
| t.procStats.InitProcStats() | |||
| err = t.procStats.InitProcStats() | |||
|
Tested on Windows and OS X, looks good and the CPU usage dropped significantly on Windows. |
added 2 commits
May 4, 2016 09:38
This decouples getting the basic state information from getting the more detailed information. The reason is that filtering only needs the name, but the code was getting all details and then apply filtering. Getting the command line is expensive on Windows, so that contributed to elastic#1460. What made it worse is that due to filtering, the command line cache was invalidated on each run, which explains why topbeat was consuming more CPU when filtering out processes than when not. Fixes elastic#1460. This also pre-compiles the regexps, which brings some slight CPU usage improvements and uncovers compilation errors earlier.
|
@ruflin there was one slight change in the API (InitProcesses now can return an error). I rebased and added a commit to add the error check to Metricbeat. Please have a look. The test and go vet should also be fixed now. |
|
LGTM. Waiting for Travis... |
|
Merging without Travis as Travis seems to be stuck ... |
tsg
added a commit
to tsg/beats
that referenced
this pull request
May 9, 2016
* Re-factor to fix high CPU usage on windows This decouples getting the basic state information from getting the more detailed information. The reason is that filtering only needs the name, but the code was getting all details and then apply filtering. Getting the command line is expensive on Windows, so that contributed to elastic#1460. What made it worse is that due to filtering, the command line cache was invalidated on each run, which explains why topbeat was consuming more CPU when filtering out processes than when not. Fixes elastic#1460. This also pre-compiles the regexps, which brings some slight CPU usage improvements and uncovers compilation errors earlier.
ruflin
pushed a commit
that referenced
this pull request
May 10, 2016
This decouples getting the basic state information from getting the more detailed information. The reason is that filtering only needs the name, but the code was getting all details and then apply filtering. Getting the command line is expensive on Windows, so that contributed to #1460. What made it worse is that due to filtering, the command line cache was invalidated on each run, which explains why topbeat was consuming more CPU when filtering out processes than when not. Fixes #1460. This also pre-compiles the regexps, which brings some slight CPU usage improvements and uncovers compilation errors earlier.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This decouples getting the basic state information from getting the more
detailed information. The reason is that filtering only needs the name, but
the code was getting all details and then apply filtering. Getting the command
line is expensive on Windows, so that contributed to #1460.
What made it worse is that due to filtering, the command line cache was
invalidated on each run, which explains why topbeat was consuming more CPU when
filtering out processes than when not.
Fixes #1460.
This also pre-compiles the regexps, which brings some slight CPU usage improvements
and uncovers compilation errors earlier.