Strange Topbeat (v1.2.1) Performance (under Windows) #1460
Comments
|
@loms0815 Out of curiosity, how many processes are there in total? |
|
Hi @tsg, if I specify filter ".*" I will get about 140 processes (=> 140 output lines in json output file) and in this usecase performance is very good! If I try to filter to one of the processes (e.g. "Notepad"), I will get this strange cpu consumption. Interesting is also the IO-Screen. Filtering seems to need a lot of IO? |
|
The I/O usage seems odd. Here are relevant parts of the process filtering code. https://github.com/elastic/beats/blob/master/topbeat/system/process.go#L220 There are some optimizations that could be made around the filtering. But maybe we should just consider removing it in favor of the conditional filtering being added now. |
|
Hi @andrewkroh, |
|
Did a quick PoC and pre-compiling the regexp seems to help. The reason it was so bad was that we were compiling all defined regexps for each process present on the system. That can add up quite quickly. The fix is quite simple, I'll open a PR with it. |
|
I was too quick with the above. It seems more related with getting the command line (which is expensive on Windows) on every call when the processes don't match the regexp. |
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.
* 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 #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. * Added error check in Metricbeat
* 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.
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.
Hi,
I have configured Topbeat with FILE output only:
Test OS is Windows 7 Enterprise and Topbeat version is v1.2.1.
If I specify the "procs"-regex-filter with ".*", then I see no CPU consumption (great). Only every 15secs there is a short spike because of storing to file.
If I configure the "procs"-regex-filter with any other filter (e.g. ".Notepad." or "Notepad") then I got a permanent CPU consumption over 5%.
So the output of all processes is much faster than to take only one process. But I can't configure all processes because in this case the file size is growing to fast!
Can you help me overcome this issue?
The text was updated successfully, but these errors were encountered: