Reduce CPU impact for SCOMpercentageCPUTimeCounter script
The SCOMpercentageCPUTimeCounter (vbs or ps1) used by Agent processor utilization rule and monitor runs on each agent every 5 minutes (321 sec) and with a sync time set to 00:00.
This causes CPU spike on virtualization hosts.
Please leave your email id in comments if you would like to test this fix.
Is this fixed in SCOM 2019 UR1? - i see - "CPU Spike issues because of workflows running on all agents at the same time is addressed through script optimization and removing the sync time"
Chris McIntyre commented
It also appears that cookdown is not working properly between the collection rule and monitor, so they are running together at the exact same time. Since it's broken anyway I increased the interval on the monitor to hopefully reduce the impact.
K Justin commented
Holman and I discussed this today.
This script has been updated with UR4, but Sync time still is an issue even with 2016 UR6.
Hoping this gets included for 2019!
As I needed to fix something else with the SCOM 2016 implementation of this, I went ahead and also changed this monitor to use SpreadInitializationOverInterval instead of the synctime currently in use. If you take the code it should be fast to implement.
Please remove the sync time from this. That seems like a very simple fix that can help a lot of us out.
Martin Ehrnst commented
Yep, i havent tought about it earlier, but I was investigating with a colleague from our data center department and we pin pointed it to cscrcript which let me think of scom.
We dont use this data, so it's disabled now.
Kevin Holman commented
I was shocked that this has a synch time. I gave feedback on this workflow when it first came out back in SCOM 2007R2. In general - I recommend disabling the rule and the monitor which both run this script, as it is very noisy for script failures and collects too much perf data in my opinion. That said - I agree - we should not use a default synch time on script datasources unless there is a VERY good reason, as we create resource depletion on virtual hosts when we do this.