I’m pushing the fixlet “Initiate Software Scan” with the CPU threshold checkbox selected and a value of 5(%). That does appear to control the scanner to 5% but the BES Client still continuously consumes 50% CPU for the duration of the scan (about 15min), This is default for the BES Client as I understand, but I want to limit the amount of resource utilization as much as possible so that 50% CPU of the BES Client is too much.
I thought I could use the cllient settings to control BES Client CPU to 5%…
setting “_BESClient_Resource_WorkNormal”=“10” on “{now}” for client
setting “_BESClient_Resource_SleepNormal”=“480” on “{now}” for client
…but after you set them, you have to restart the BES Client, which prevents me from doing it all in the same Initiate Software Scan fixlet.
Any suggestions how I can 1)Restrict BES Client CPU to 5% and run a Initiate Software Scan with 5% CPU usage all int he same fixlet?
Actually the BESClient default CPU should be 2% when not running any actions, not 50%. The scan should be launched in detach mode and not using the BESClient cycles. are you sure that there is not something else running that is actually rising client CPU usage to that value, before messing with default settings?
My bad… you are correct.
I did remember that the scan was launched in detached mode, so the agent had to go back to Idle, but after checking the scan fixlet I see that it is launched using runhidden(windows) and run(Linux & others). So agent goes to normal mode that uses 50%.
Not sure if is just my bad memory and the sw scanning fixlet was changed at some point, or if it has always been this way. (BTW the fixlet comments say “// ###### RUN SOFTWARE SCAN BACKGROUND SCRIPT ########”)
As the problem is about scanning sw you may try to:
make sure that the scan is the last “meaningful” action of the fixlet (it triggers multiple data collections, some within runcit_sw script and some outside it) and
change the fixlet to use rundetached (at least on windows), so the agent is actually ending the action and going back to normal mode.
I created new fixlets to set WorkNormal and SleepNormal to 5% and restart the client before the scan runs and then revert afterwards. It’s not ideal but I think it will have to work.
To your point, it’s unfortunate that the fixlets use “run” rather than wait. I guess they didn’t want the fixlet to be “Running” when the scan takes hours. However, I want the action status to actually represent what is going on so I added a pause while at the end of the Initiate Scan fixlet to pause while there is process running that starts with “wscan”, whicih helps.
So i think this is the best setup but it seems like an oversight by IBM that they advertise that the scan can be limited by CPU when I guess it can, but the BES Client still goes wild.
You may want to open a support case for BFI or ILMT (depending on what you are using), to see if they recognize that the sw scan should actually release the agent and let it to go back to its idle condition after submitting the scan (as I remember it was). In the case you don’t have to change the default settings of the agent and do any special tricks (in my experience agent’s settings in general are tuned to a good balance ).
While an action is running the client uses the “Normal” Work/Idle settings until action processing is completed. This by default is 50% of a processor. You can change the values of the Normal pair to be a lower value, though generally on a modern processor (dual core with SMT) thats 50% of 1 of 4 processors so generally isn’t even noticed.
Also changing these values does not require a restart of the agent, but the agent doesn’t necessarily do it immediately either.
maybe it was a delay in the settings but during my testing, if I changed the Normal Work/Idle settings in the same fixlet as the Initiate Software Scan, the BES client CPU usage would remain at about 50%. I only found it to slow down after changing the setting followed by “client restart”.
If an action changes the setting then it should get reset during the action. Otherwise a “loop” through the current type of content must be completed before the settings are re-read and adjust behaviour (if you do it manually for example)