We've noticed that on nearly all systems that have been upgraded to VSE 8.8 Patch 4 that their On-Demand Scan jobs are taking longer to run than before. I've looked at a good sample of machines ranging from user systems, test environments, development servers (DB, file, web), and production servers (DB, file, web).
The length of increase seems to range from 1.5x to 2.5x longer than before. Basic machines without a lot of files were taking 15~20 minutes before P4 and now they take 30~40 minutes. One of our main development web servers was taking 2.5 hours and now it takes 4 hours. One of the main production web servers with lots of files on it went from 2 hours to 5 hours for the On-Demand Scans to finish. We run the ODS every night and the machines only reboot monthly for patches. All of these time increases occurred the day P4 was installed ad it was the only item installed. The new extended times have continued since the first patch day not decreasing.
We've rebooted some of the systems after P4 installation and some have not and computers in both categories are showing the extended scan times.
I've looked through the known issues information and nothing sounds like it would cause this.
I verified in ePO that the General Options Policies -> Global Scan Settings -> Enable saving scan data across reboots & Allow On-Demand Scans to utilize the scan cache are both enabled still.
I know there's the new write scan delay technology but all of the servers being scanned are pretty much idle for use when the ODS jobs run.
Can anyone else verify they're seeing this as well to please?
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.
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?
I harvested it from the logs on a sampling of machines across the various types of OS and function. Every single one of them had increased ODS scan times. I looked at the historic entries in the scan log file and most machines will on average take a similar amount of time from day to day so when that value jumped and stayed at the higher new time it made me concerned.
I have an open case with support now, they're reviewing provided logs.
Same here - ODS takes longer after P4.
We do have dailly morning scan task to scan user profiles. To avoid it running into business hours time limit is set for 30 minutes. It was enought for P2, now on P4 it was cancelled after 30 minutes when still scaning.
Our scan task priority was "low" now I had to change to "normal" and it is again finished in time.
Dear McAfee - could you please include "task run time" field in "Task completed" event so we can use it in reports......
there is an on demand scan log that is generated here: %DEFLOGDIR%\OnDemandScanLog.txt. Within this log, it will give you the total amount of time your scan took to run. You would compare these from week to week.
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. |
|6 (maximum number of threads)|
Can you help us understand this better.
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.