VsTskMgr and Engine Server service should not consume that much memory. The processes may jump that high but the memory should be released after the actions are performed. Please insure that you are using the 5400 Engine as you may see a small memory leak with the 5301 engine. Outside of that with some configuration of VSE you should be able to run VSE seamlessly.
Actually, it looks like I am running the 5301 engine, how would I upgrade to the 5400 engine? I am fairly new to this, it was just thrown on my lap since there was a problem and no one else could figure it out.
Thanks for your help!
You can download the engine here http://www.mcafee.com/apps/downloads/security_updates/engines.asp?region=us&segm ent=enterprise
You will want to download the exe and run it on the laptop then reboot.
When you see a Mcafee process spike in memory usage like that, you can be pretty confident it is a process that is loading our DATs and Engine (for whatever reason). In the case of EngineServer.exe, that service provides scanning functionality for non-OnAccess Scanners.
In 8.7i Patch 1 and later there are memory management improvements, specifically in how the DAT files are handled, that would apply to EngineServer.exe. I suggest that be your starting point for any performance testing; patch 2 is the latest patch, so that would be an even better baseline.
Note: To make sure you have the latest VSE "stuff" you can refer to this article: KB65944.
However, even with current patch levels, it is possible for the product to revert back to using the older DAT memory management system which consumes more memory. This is described in the Patch 1 readme under the Known Issues section (included here for convenience):
In some situations, the product switches over to using the normal copy of the DAT files, instead of the runtime DATs:
- If the McAfee AntiSpyware Enterprise module is installed after VirusScan Enterprise 8.7i Patch 1 is on
the system, some of the new registry settings, which are new for the runtime functionality, were
changed back. This resolves itself with a restart of the McTaskManager service or with a reboot.
- If one of the scanners is busy on a large file when the AutoUpdate process posts the revised copy of
the DATs, the process of refreshing the runtime copy of the DATs times out. All scanners use the
normal DATs until the next successful update.
The second described scenario is more likely. On the next DAT update or system restart, the product will again try to use the improved memory management scheme - but again, if it fails, it'll revert to the older method. This takes time. And it could be what's happening in your observations. It would be good to have that verified if you are willing to collect some data and pursue an investigation with the McAfee Support team, because if confirmed then it would encourage McAfee to continue looking into ways to solve this.
There is also a registry tweak that lowers the thread priority of the Agent, which is responsible for doing the update; its processes are often coupled with VSE's when describing performance issues during updates: KB53690
A similar tweak exists for the Mcshield.exe process but this is seldom needed, and not documented. Support would recommend that change under advisement by Tier 3 Support if an escalation warranted it, for that reason I don't publish the details here.
The 5400 engine as suggested earlier is also needed - this is included by default in our current posted package that includes Patch 2.
I hae seen this problem in my org off and on. your suggestion to download and update the engine to 5400: this can be done per machine and not affect the delivery of server pushed updates? Or, should this be done from the server side to update every machine?
I am currently not responsible for managing the McAfee product directly, however, in the capacity of a helpdesk technician I do the troubleshooting. since this has been a problem for some of our users I like to look deeper than just stopping and restarting a service.
Thanks in advance.
You can update the 5400 engine separate from ePO's updates without affecting the rest of the organization.
The systems you do update will report back to ePO that they have a newer engine version.
To do this you can -
a) Use the SuperDAT engine update package, which we know only works for 32-bit systems. If this isn't a limitation for you then it's recommended.
b) Obtain the engine update files from the ePO engine update package, "Engmin.zip" and "Engmin64.zip" for 32-bit and 64-bit respectively, for updating the files manually.
Further guidance on manually updating the engine can be found here: KB60795. Although the article refers to 5301, the same steps apply with minor difference.