We`ve seen the same thing. It`s a lot worse on XP than on Win7 though, on the same hardware.
I`ve yet to see the promised speed boosts that were promised by VSE 8.8.
If you consider that VSE 8.8 came out , and filled up even logs with endless pointless errors, and then a security hotfix came out and had a bug that prevented you from upgrading the Mcafee agent, and then Patch 1 shipped (WITH a seperate hotfix...right from day 1), and it was breaking HIPS and solidcore, and now VSE 8.8 patch 2 will be 6 months behind the original promised date before it gets released to the world...and that;s WITHOUT considering the other performance issues, or installation weirdness if there is a UNC value in the path, or other issues.....well..overall, VSE 8.8 sure looks like a really shaky product.
VSE 8.7 had it`s issues and it`s flaws, but you could count on it and and it seemed a for more "solid and reliable" product than VSE 8.8 is, by quite a margin.
And then then promised new engine (5500) release was scrapped and a new engine, 5600 will be in beta in the new year with full deployment in June 2013...
When you look at the last 18 months of history for Virusscan and it`s components, it`s really a horrible mess of broken promises and really poor products.
Meanwhile, we are bombarded by an ever increasing amount of malware and threats, and the product that is the last line of defence, the one that is supposed to be our fail-safe..the one that will save and protect us if all the other layers somehow fail...it`s in shambles....
I know this is harsh to hear..I really like Mcafee products and I have great SE`s and such and they are awesome....but VSE 8.8...sorry guys, but it`s a dud...
We actually resolved 2 system level issues that were causing several users excessive CPU consumption of McAfee VSE 8.8 P1 with the latest hotfix. I wouldn't call these issues with VSE itself as they were more system issues causing excessive VSE CPU consumption on W7 systems. These are all quad core or greater systems with 8 GB of ram.
Issue 1 - The first was a user with a 20 GB Outlook 2010 PST (2003/2007 upped the limit to 20 GB and 2010 upped it to 50 GB). That problem was the fact that they had 10+ years of email in one massive & fragmented PST and the way Outlook & the Windows Search Indexer interact. The Search Indexer notices the PST contents have updated so it begins a index process against the PST. Well when you have Outlook's fingers in the PST, Search Indexer, and McAfee all at the same time going after the same content inside of a massive & massively fragmented PST you're obviously going to cause heavy CPU consumption. We saw typically full usage of 1~2 CPUs.
Resolution 1 - Breaking a users large PST files down into multiple smaller PST files based on year resolves these issues. This allows for the content of previous years to reside in PST files that stay attached to Outlook so they get indexed but since email is never going into the older PST files they never trigger re-index or VSE scanning. You have to make sure to compact the original PST when you're done splitting content out of it.
Issue 2 - One group was hacking the installation of Adobe CS2 to work on W7 64bit which is not supported. This resulted in context menu items being created that were not supported by W7 and were causing multiple issues. Any time these users would right click it would trigger the context menu items and would result in 100% McAfee CPU usage across all cores. This would continue to go on like this for at least 30 minutes until it had worked itself out but would start all over again the next time they right clicked.
Resolution 2 - Just uninstalling Adobe CS2 did not resolve this issue. We had to use a tool to edit the items in the context menu to remove the entries left behind by the CS2 uninstallation. After these items were removed the machine returned to normal CPU usage.
Interesting issues Brentil! I've not had those same symptoms filter their way up to my ears, so perhaps a reasonably unique use-case you have there. I've had my own battles with large PSTs, not quite what you described though. The context menu issue sounds like the performance hit would've been "Access Protection" related, where we are being bogged down in registry processing code and comparison checks against the numerous registry checks a right-click invokes.
Ottawa_Tech_31, I know how you feel; and have heard those concerns multiple times. But I know the 8.8 product well enough to know without doubt, it's speed is superior to 8.7i. Where folks feel differently, it has always been due to adopting a practice or configuration setting that we do not recommend.
And, here's hoping that Patch 2 solves the world's concerns ... just as soon as we get it out the door! LOL
As far as best practices go, please consider the following and checking them against your environment -
1. OAS configuration -
- DISABLE the setting for "Processes on Enable"
- DO NOT scan archives
If you have performance complaints from users and confirm it is from file-based scanning alone, and not one of the other below mentioned items, then you have something worth investigating. You'll want to understand what is being scanned on that user's system.
2. ODS configuration -
- DO set the "CPU Utilization" to "Below Normal" or lower.
- DO NOT scan archives
- If you include NON-FILE scan targets in your scan task, then schedule the task to occur when Users will not be on the system
(that means, Registry + Memory + Rootkit). These scan items DO NOT adhere to the CPU Utilization setting.
3. Email Scan -
- DO NOT use this feature for Roaming Users
The mail has to be scanned across a much slower connection.
4. ScriptScan -
- Be mindful that IExplore.exe renders all scripts before displaying a page, so ScriptScan has to do all its work when immediately going to the site
vs. FireFox, which handles scripts more dynamically, rendering them when needed
- Exclude your Intranet sites in the ScriptScan URL exclusion feature, and DO NOT disable the ScriptScan BHO as that's essential for URL exclusions to work!
- Use Patch 2 when it's available
5. Updating -
- Confirm if your user complaints coincide with when the DAT Update takes place. It shouldn't be too difficult to do with their call time and log files.
- Ensure the VSE product is "healthy", there have been some issues that cause the product to always download the full .zip on update, which is bad.
- DO use the Agent thread priority tweaks described in the knowledgebase
- Use Patch 2 when it's available
- It won't be long now, but some Update DAT script changes are coming that will reduce the overhead placed on any given node when the update runs. In many cases it'll be quite noticeable (or should I say less noticeable?). Instead of copying the monolithic DAT file that's created post update from one folder to another, it'll be renamed!
In relation to 8.7 vs 8.8 I've done a bunch of benchmarking of the two applications and for the most part 8.8 is hands down better than 8.7 AS LONG AS you keep the setting on to maintain scan state between reboots.
The 2 best tools for hunting down exactly what the problem is on the user's system outside of the McAfee settings is the OAS Statistics page & MS Process Monitor. I always start with the Statistics page because it is easy and quick to bring up on a user's machine.
OAS Statistics page
- VirusScan Console -> click on On-Access Scanner -> Task -> Statistics
- Watch the "Last file scanned" to see if something in particular is keeping McAfee's attention
- Setup a filter to only include mcshield.exe
- Grab some popcorn as you sift through lots of data
Of note the machine with the context menu issue had problems with OAS disabled too, but just 1 CPU worth of consumption. Once you turned it back on though is when it would go to all 4 CPUs at 100%. We chalked that one up to user error though as they force installed a product we told them not to install.
I usually use McAfee Profiler in this cases to know what files n process VSE scans.
With this toll I Know how many times i have I/O of the process.
If the Process who takes long scans and this process is a valid process maybe can be valid Exclude this process of VSE
I hope I have helped!
Brilliant, how did I not know about this tool!
I actually had a new case brought to my attention just now we hadn't seen before. A user clicks the Attach File in Outlook 2010 32bit and McAfee goes to 100% of 1 CPU making the browse window super slow to load. Then when they're trying to actually browse for files and time they move folders or attempt to scroll in a folder it goes to 100% of 1 CPU and makes it jitter up and down in a rather nasty manor. When you use a folder browse from anywhere else though there are no issues with performance. I tried from several applications with no spikes of CPU usage at all. I tested it on my machine and I didn't get the massive CPU spikes they're getting but I do get a CPU spike when ever I enter a new folder from the browser in Outlook that I don't get from any other folder browser.