I can definitely confirm performance issues following patch1 in our environment however I have not seen the behaviour your describing around the ODS scans. We have our weekly scan scheduled for after hours; some do run the morning after but have not heard complaints around the weekly scan.We are receiving a number of complaints around the OAS, it is causing Java applications to be unusable in some cases. We have submitted a SR that has been escalated related to this issue. I am also in the process of implementing a daily scan, so I will watch for the issues you are describing.
Some informations in this KB
McShield.exe and Scan32.exe behavior
To reduce memory usage in VSE 8.8, the On-Access Scanner (mcshield.exe) uses the instance of the DAT files and Engine already loaded in memory. As a result, when an On-Demand Scan (scan32.exe) is launched, it uses the McShield.exe process. For this reason, you may observe higher than expected CPU usage by the mcshield.exe process.
The Daily Mem/Proc ODS is scheduled to run every morning after dat update. Then i can see McShield owning all CPU. The problem is here
Full ODS Workstation is scheduled to run in lunch time 12:00 PM. So users do not complain.
Full ODS Servers is scheduled to run at sunday at 4:00AM. No Complains.
Just did some testing on this, as you had indicated any type of ODS scan is maxing out CPU, on multi-core systems it uses a single core. This is much easier to reproduce then the Java issues we were seeing, I will bring this up as part of our escalated service request. I also saw in another thread about the update task causing similar issues, we are also seeing that on single core systems. I am also looking to confirm is 8.8 without patch 1 experience this issue. Have you submitted a SR yet?
Already opened a service request. Support has sent an application called McAfee Profiler that can bring the profile of the processes and files to make a policy of exception to fix the problem.
But I think it is not the solution.
Could you tell me if you have any solution?
I think the McAfee Profiler is more for identifying individual problem processes. I think this is just a general problem with patch 1. McAfee got back to me today regarding the SR I submitted and they are acknowledging there is an issue and they have asked us to run additional tests. I will provide an update once I know more.
Thanks ! If i have an update ill provide.
I have seen similar issues when doing scans of Running Processes. On some low horsepower machines (ATOM processor) and trying to scan a process that uses about 300 to -500 MB of memory, it would bring the machines to a halt for 10 to 20 minutes. We were told there is no way to exclude certain processes from the scanning of of Running Processes. So we had to turn off that protection. Over in Product Ideas there is a suggestion for adding some flexibility to the scanning of Running Processes.
Anything new on this issue?
We are still working with McAfee, we just completed a remote session and collected data from our test environment where we are reproducing these issues. We are waiting to hear from the engineering team after they analyze the data. If you are experiencing similar issues please submit a service request so McAfee has further data points and can see the impact of the problems associated with this patch.