I noticed several customers complain about mcshield high CPU consumption.
The customers are using VSE 8.8 P1.
All customers have configured 3 ODS.
1) Daily Memory/Process Scans
2) Weekly Full Scan - Workstation
3) Weekly Full Scan - Servers
When Mem/Proc scan occurs, McShield is taking all CPU. Crashing all workstations for a short period, like 10/15 minutes.
They had the same configuration in VSE 8.7 P5/ VSE 8.8 without Patch, and this problem not occurred.
Somebody knows about this issue?
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.Message was edited by: jperry on 2/27/12 7:28:42 AM CST
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.
=/Message was edited by: josevicente on 2/27/12 11:10:48 AM BRT
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.
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.
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.Message was edited by: jperry on 13/03/12 11:17:26 CDT