We have noticed the same Issue on our Servers since we´ve updated to Patch 4.
The Scan-TIme for On Demand Scans increases nearly three times und CPU-Consumption raised.
Sorry but I´ve still no solution for this Problem too. We downgraded to Patch 3 as a try and we ´ll compare again.
The reason I discovered this was we had some webservice calls that happen after hours to do some system maintenance and they were failing at the same time every night. I started looking into what was running at the same time and found the ODS jobs were taking way longer than before and the higher CPU usage was causing the webservice calls to time out.
This tidbit from the Patch 4 readme is relevant:
New or changed setting Registry entries DWORD default value On-Demand Scanner is now limited to one thread per CPU, 6 threads total by default. This limits the amount of memory used by ODS. • To activate this feature, the System utilization slider setting (on the On-Demand Scan Properties, Performance tab) must be set to Below Normal. • To change the maximum number of threads, set the DWORD value. • To deactivate this feature, set the DWORD value to "0". • 32-bit systems:
◦ dwUserDefinedMaxThreads • 64-bit systems:
◦ dwUserDefinedMaxThreads 6 (maximum number of threads)
Can you help us understand this better.
- What was the configuration before that was allowing the scans to complete faster?
- According to that to enable this feature it must be set to "Below Normal" but in ePO on the Performance tab of the ODS Task it is set to Normal. Why then is scan time being impacted?
- Is there some other way in ePO to configure this I'm missing?
You'll want to work with Support for specifics on changes to make that may suit your environment, but I also say that because I recall an open investigation one of the team is looking into where tweaking the settings wasn't producing the desired result. So, there may be an issue here with the code; that remains to be seen.
The dwUserDefinedMaxThreads value and supporting values are not ePO configurable - this was a "quick fix" to the escalations we received where ODS was using gobs and gobs of memory. It's likely you were experiencing this too but saw no impact from the behavior.
FYI, it's advisable to set ODS to "below normal" priority, which may actually solve the issue you're seeing with the webservices. The scan times for a "normal" vs "below normal" scan are not markedly different, when using the same number of scan threads - but a "below normal" priority means Users (or other processes) always get the CPU time they want/need.
I guess I'm confused then. The documentation you posted above says "To activate this feature, the System utilization slider setting (on the On-Demand Scan Properties, Performance tab) must be set to Below Normal." So shouldn't it being set to Normal not enable this feature at all based on this description?
Yes, but there are some assumptions being made there that we need to iron out.
The concern is that perhaps this new feature, while doing 'something', may not be doing what we expected it to after all.
We can update this thread with the conclusive results/analysis once we have them in hand, but if you want to learn the same sooner you'll want to ping our Support teams who can work through the details with you.
Thank you, I will start the support ticket then.
How did you measure the increase in time?
I ask because I'm in the process of testing patch 4 in a limited pilot environment prior to rollout and I'd like to look for this type of symptom before I roll the patch to a wider population.
Did you "harvest" this from the log file(s) or did you come up with a clever ePO query?