Has anyone else noticed issues with large client downloads (over 500MB) taking a long time. The client typically takes 10-20 minutes, can take longer on slower systems, from the time the file was downloaded until the time the action starts. I opened a PMR in the past for this issue and was told that the delay is due to the client calculating the sha256 value.
In the past if I issued a client refresh it would speed up the processes. The refresh allowed the client to use additional cpu, making that evaluation quicker.
Now that we’ve upgraded to 9.2.5, the client does not respond to a refresh or log anything from the time the files are downloaded (I know they’re downloaded because I can see the file size stopped growing) to the time the action starts. I assume this is during the sha256 calculation. Because of this we can no longer speed up the process by sending a refresh.
Even if the file is downloaded ahead of time, there is still the 10-20 minute delay before the action starts, because the client has to calculate the sha256 value before starting the action. This can be a problem for us when trying to preform application updates within a change window (the action never starts on time)
Have you thought about just increasing the CPU utilization (WorkIdle) during the change window and reducing it after the change window? We would typically set the workidle to 500 (Allowing BigFix to use 100% of one system core) in cases where we knew we had a large number of changes to push to a group of clients in a short amount of time.
The limitation here is that the action you are trying to perform requires more CPU cycles than the client is allowed to consume across the change window. If SHA2 hashing was allowed to use more CPU than the workidle of the system then you’d be violating the CPU limiting features of the bigfix client.
If you wanted to verify what the client is doing during this time you could monitor besclient.exe using a tool like process monitor – this would tell you if it’s hashing the file or doing something else.
I have thought about it, it’s an option, but not ideal, or always practical, which is why I created the RFE.
The client is already allowed to use additional cpu as defined by the _BESClient_Resource_WorkNormal and _BESClient_Resource_SleepNormal settings, for the following tasks:
gathering sites
running actions
processing refresh requests
processing client compliance api requests
Why can’t it be allowed to use additional cpu for download request as well which are related to actions? Notice item 2, this is a separate issue, but I’ve found that while my actions are executing the cpu spikes between 10-60% during the entire action run, as allowed by the work and sleep normal settings, but the client is not allowed to use any additional cpu to evaluate the sha2 value and start the action…
The issue here is different customers are more sensitive about this. If a precache is done to the download, this would mean elevated CPU in arbitrary positions compared to when the action is actually done.
This is just one of the “its harder to do than you think” kind of things I can bring up, where a solution works well for some people just not others.
You could also argue that we should enter elevated CPU stage when the download completes and thus the action is ready, and THEN do the SHA of the file, but if the SHA doesn’t match then we have elevated for no reason.
The hope at one point is to do the SHA as the file downloads but that can be problematic as the thread that performs the download isn’t actually restricted, so while this does what you want, it won’t be a good solution to everyone.
Now you probably see why we have so many setttings
I would recommend upping the CPU usage of the client a bit, but definitely not to 500, and it should help.
I didn’t know about this issue, and I can definitely see why it would be an issue.
Most of the time when sending out an action, I don’t need it to happen very fast unless I’m debugging.
If an action is going to run during a maintenance window and it is set to download before constraints are satisfied, does it have the same delay issue, or does it calculated the SHA2 ahead of time?
@jgstew yes, we have the delay even when downloading before constraints are satisfied. The sha calculation happens right before the action starts, but doesn’t get to use elevated cpu, like the action does.
@AlanM I get the concerns, but the sha calculations are very important, and can obviously take a long time. I think they should either get to use the normal cpu limits, like actions and gathers do, or a new cpu limit setting gets created that customers can use to set how much cpu they want this evaluation to use.
