BESClient Constant CPU Usage

[casmxg]

One of our more technical employees has raised an issue regarding the BESClient constantly using CPU. To be clear, this is not an issue with the amount of CPU being used, just that it never uses 0% CPU.

These are the direct quotes from the requestor:

The new BigFix service “BES Client” (C:\Program Files (x86)\BigFix Enterprise\BES Client\BESClient.exe) is constantly using cpu. Not a lot, but it never sleeps. Task manager show 1-3% cpu usage for this service 24/7, which is not how any well behaved program should operate.

Sorry, but this is not how any well written windows (or any other) application is written. I can write an app to continually scan the entire hard drive and not constantly use cpu like that. It is constantly spinning the cpu because the code is garbage. This is not something that should be accepted in enterprise grade software as “oh well”

This was my unsatisfactory response:

This is expected behavior for the BigFix Client. The BigFix Client is always active in the background, processing and evaluating objects like fixlets, tasks, analyses, and inventory, and relaying results to the server. The BigFix Client will never exceed 5% CPU with our current configuration.

Here are my questions:

1. Is an application that constantly uses CPU poorly written?

2. Can someone provide links to HCL/BigFix KB articles that can explain away this issue?

3. Can I use configuration settings to alleviate the issue?

I have reviewed these forum articles:

BESClient CPU usage constant on 2 to 2.5 %

Hello guys, I have few clients on which CPU is always constant which is around 2 to 2.5 %. I have created analysis for evaluation time of action and relevance. Name Eval % Relevance … Eval % action … Evaluation Loop Average … Actual max % of CPU of Client Name … …65.8 …0.6 …00:00:29.451684 …2 The load on the machine is not much as the server is subscribed ti 1 site only i.e. SUA Please suggest on this. Agent Version 9.2.1.48

Automatically adjust BESClient settings when on battery power

This is something that I am fairly certain that I can do using existing relevance & actionscript, so I guess this is more of documenting an idea that I plan to implement rather than a true Enhancement request. I am frequently in the middle of testing BigFix content, and often wish that the BESClient was more aggressive. This often leads me to set the client settings to be very aggressive on my testing machines, but this has a very negative affect on battery life of my laptop. It occurs to me th…

I have applied the following settings to two systems and have not seen a change in CPU usage behavior for BESClient:
I have also tried setting _BESClient_Resource_AccelerateForPendingMessage = 0.

_BESClient_Resource_AccelerateForPendingMessage	1	Local	
_BESClient_Resource_PowerSaveEnable	1	Local	
_BESClient_Resource_PowerSaveTimeout0	10	Local	
_BESClient_Resource_PowerSaveTimeout1	15	Local	
_BESClient_Resource_PowerSaveTimeout2	30	Local	
_BESClient_Resource_SleepIdle	460	Local	
_BESClient_Resource_StartupNormalSpeed	0	Local	
_BESClient_Resource_WorkIdle	25	Local

We also have these settings configured and I’m not sure if they are interfering:
I inherited these settings, so please let me know if they are incorrect.

_BESClient_Comm_CommandPollEnable	1	Local
_BESClient_Comm_CommandPollIntervalSeconds	900	Local

_BESClient_Download_FastHashVerify	1	Local	
_BESClient_Download_RetryMinutes	1	Local		
_BESClient_Download_CheckAvailabilitySeconds	120	Local	
_BESClient_Query_NMOMaxQueryTime	30	Local	
_BESClient_Query_SleepTime	500	Local	
_BESClient_Query_WorkTime	250	Local	

Any feedback on this would be greatly appreciated. Thank you!
_mxg

[DanieleColi]

Hello,
The BigFix Client is in a constant loop of evaluating each Fixlet message, Task, Baseline, etc. to see if it is relevant and take immediate action.
So, a bit of CPU usage is always expected. The example

@casmxg

I can write an app to continually scan the entire hard drive and not constantly use cpu like that.

does not fit our Client, as the evaluation activity mainly requires computational resources (CPU) rather than disk access.
The PowerSave settings will reduce client activities, but if your cpu usage graph is almost flat (and by default client settings force minimum cpu usage), it’s hard to see any difference. The setting _BESClient_Resource_PowerSaveDeepSleepEnable uses a more aggressive power save.

Some references

Configuring Client CPU Utilization

List of settings and detailed descriptions

[JasonWalker]

Agree completely with @DanieleColi 's assessment. To prevent the client from doing its normal background evaluation, you’d utilize the PowerSaveEnable settings as you’ve done, and the _BESClient_Resource_PowerSaveDeepSleepEnable setting applies a stricter sleep where the client will not wake, even if it receives a UDP message about new actions or Queries. That’s used chiefly in low-battery configurations but feel free to use that if the CPU graph is bothering you.

Another note on the settings you’re talking about though -

@casmxg

_BESClient_Resource_SleepIdle	460	Local	
_BESClient_Resource_WorkIdle	25	Local

In that configuration the client uses more than double the CPU throttle than the default values of 480 Sleep / 10 Work. With those settings I would expect to see the client use something like 10% of a single core, constantly; with the benefit that if something changes on the machine (a patch is uninstalled, software removed, service added, whatever), that result will detected and reported more quickly.

CPU throttles generally are an act of balancing how quickly you want to see changes versus how little you want to affect the workload of the machine.

Our published content (along with whatever custom content you have) is much more than just a “list files on the disk”. Retrieving versions of files and services often uses Win32Api or glibc calls beyond just disk I/O. There is also a lot of Registry search which can be intensive, and a fair bit of WMI calls (which spawn threads of their own and can consume CPU).

[bigfix.mark]

IMHO there are a lot of misconceptions about core usage in a multicore/socket deployment. The simple answer is the agent is very efficient (amazingly so) and when it has work, it does work. It is effectively throttled down and distributes workload over time.

We are getting a very short window in the scheduler to drive the work, without impact to other applications. It is of course possible to write bad apps, but the agent is not one of them. CPU resources are used judiciously. Path length is rigorously maintained.

When we do performance work we often see the many pervasive processes that are driving continuous utilization. These apps are primarily in the security space, and purpose built. This is not typical application code, rather it is based on continuous event processing.

Interestingly enough another inquiry we get is around high memory usage. The kernel is typically driving this as it rightfully assumes if it has memory, it will use it and manage the threshold to maximize throughput. Overall, like the kernel, we consider the ability to judiciously manage resources over time one of the best features of BigFix.

[casmxg]

Thank you @DanieleColi, @JasonWalker, and @bigfix.mark for your response and insight. It is difficult to single one of you out as the top contributor, as you all provided valuable and relevant information. I will pass this along to the requestor and see if this satisfies their curiosity.

Regards,
_mxg