High memory consumption Adaptive Threat Protection

[GGsxpUGy5xWec]

Hello everyone,

Due to the high memory consumption > 80,533.7 MB < of the McAfee Adaptive Threat Protection Module, the system (a Windows Server 2012 R2) became unusable.

A problem that should be fixed with the installed February patch.

Version ES Plattform        Produktversion 10.6.1.1206

Version ES Threat Prevention        Produktversion 10.6.1.1273 

Version ES Adaptive Threat Protection        Produktversion 10.6.1.1164

Has anyone had similar experiences?

Is there already a solution to the problem?

[Former Member · Accepted solution]

When you installed the Febuary Update was the system rebooted? If not, please make sure you do so as it will release the memory and most known issues for high memory were addressed with this patch level.

We would ask you to submit a set of data to us, so we can validate what is causing the high memory usage. To start with a process dump and a MER with ENS debug logging enabled would be great - see KB86691 for more info.

Is it safe to assume that this memory consumption grows with time? If so, how long does it take to get to this state?

[GGsxpUGy5xWec]

Thank you for indicating that a restart is required.

Since this is a production server, no reboot was performed after installation. There was no hint on the system side. Even the large number of systems would make a required reboot a problem for us.
To get around the problem we had to take out the ATP module first,
so it doesn't make sense to send logging files now.

[Pmaquoi]

i have sometimes the same issue and 'im readying the february update to solve this case. but generally, each ATP update should be followed by a maintenance reboot for the target. for two reason, freeing the memory and also, to be able to reactivate all submodules after the update. Without the reboot, some options could be offline.

Philippe

[bodysoda]

In fact Windows has an event on the Application logs with Event ID 1029 / Source - MsiInstaller indicating the ENS patch was installed and the reboot will be deferred. 

Product: McAfee Endpoint Security Platform. Restart required. The installation or update for the product required a restart for all changes to take effect.  The restart was deferred to a later time.

We have our monitoring system to look for event id 1029 with search string "Restart required" to raise an alert. I suggest you to explore some of these options.

[GGsxpUGy5xWec]

Many thanks for the feedback, I think I will install such updates in the future if the WSUS updates are also installed and a restart is pending anyway.
The large number of systems contributes to the fact that such things cannot be handled as flexibly as it would be useful.

[Savage]

No amount of reboots will help.

If you reboot the server with ATP at max Memory utilization all it does is restart the services. You have a 50/50 chance of it happening again.

We have loaded the May Patch to help with the issues of the Feb patch and even after that it still randomly re-occurs.

There are no defined parameters that cause this memory leak as we have experienced it across multiple technologies, multiple patch levels of Windows as well as McAfee as well as Windows OS.

It does however seem to be more prominent on Server 2008 R2, And Windows 2012. not sure if we have had it on multiple 2016 servers yet.

We have a ticket open with McAfee but at this stage disabling ATP keeps the system admins and business happy. But its not the right solution.  

[Pmaquoi]

First of all, the  July update should contain once again an mfeatp memory improvement for this bug (info from the support)

As a workaround, i have implemented for my servers a service reset process that will kill and restart the service (based on an article published last year in a KB) automatically. On some servers i launch that process (Don't forget to add the executable into McAfee autoprotection exclusions) each 48H, or on some others in response when the memory start to reach a limit i fixed. It is a quick win really.

As patches are delivered, i must admit that this issue is becoming more rare actually

[Savage]

Hi there.

Thanks. Problem is the server support is out sourced.

We are not able to implement service resets ect and if we could it would take at least another month to get that approved and then tested and working. 

"As patches are delivered, i must admit that this issue is becoming more rare actually"

Well im not sure. we have had endless issues with the ATP module and memory leaks since last year and in our case it seems to get worse every time. 

[Former Member]

Dear @Savage 

If you have not yet done so and you are still seeing the memory leaks with the July Update released yesterday, I would suggest collecting data as per the following KB (see memory leak) and providing it to support so that we can investigate why you are seeing these issues in your environment. It could be that you have a very specific setup/ environment and hence you are seeing a rare scenario that others have not reported and therefore we would not know about it. We would love to get this issue resolved for you!