I noticed when I run epo task (Disaster Recovery Snapshot ) the memory jumps from 12% to 30% and the sql server memory usage jumps from 377 MB to almost 3 GB, when the task is completed the memory percentage stays at 30% and does not go back to 12! also the sql memory usage stays at 3 GB!
I noticed when I run epo task (Disaster Recovery Snapshot ) the memory jumps from 12% to 30%
That sounds like expected behavior. If you think it is not check with the ePO Support team.
the sql server memory usage jumps from 377 MB to almost 3 GB
You just told the server to do a large amount of work, so again that sounds expected.
when the task is completed the memory percentage stays at 30% and does not go back to 12! also the sql memory usage stays at 3 GB!
Welcome to Microsoft Windows operating system.
Neither of these is a bad thing.
What stays in memory is up to Windows, and optionally up to the application. If you do not have sufficient memory, Windows will literally kill itself trying to keep your applications happy in providing them the memory they need. Or, you could provide the system more memory. But if you have sufficient memory, this should not be of any concern to you.
Memory is a resource. If there is available memory there is no need to release memory that has already been used.
When memory is needed, if none is available, Windows will engage in algorithms to reclaim memory pages so they can be used by applications that need it. There is also a pagefile that allows for there to be much more memory than just the installed RAM, all of which is managed by Windows in the most optimal way possible.
Our own observations of this behavior are therefore meaningless, unless it can be proven that there is an issue to investigate... memory usage of itself, even gigabytes of memory usage, is not of itself an issue to solve.
thanks for your helpful reply you are right I run the snapshot task again and it stays at 3 GB it did not take more, but I noticed that the snapshot task takes 30 minutes and the on-access scanner takes 100% cpu, if I exclude the epo directory the task takes 2 minutes! any idea to avoid this and what subdirectory to exclude from the epo instead of excluding the whole epo directory ?
I appreciate your help again
For High CPU usage issues that you have already confirmed are associated with the OAS, the question to ask is "What is being scanned?"
The only way to discover this is to record the file activity that's happening during the high CPU event, and examine it. Then determine how the current OAS configuration can be modified to provide relief (or even if that is the right thing to do).
We have a tool that can help you see what the scanner is inspecting, called Profiler.
Thanks for taking the time to reply. We have an open SR # <4-11256096511>, to which we have uploaded MER and log data. So far though no info from Support, I have tried calling but could not get through. Any help much appreciated, we have to manually restart these hosts overnight, and being as we have 200 servers in our Warwickshire schools - its a big problem. We could just uninstall the AV, but I would rather find a fix/reason to our issues? We had been running Agent 5.02/VSE P5 without issue ....
I took a look at your SR and the perfmon log provided; it showed the memory usage issue but was insufficient for showing the leak.
So there are 2 useful approaches to troubleshooting -
I made these recommendations in the SR that the technician can pass on to you also, since this is not a place to be used for Support tickets.
you have scared us when you said that you had to restart 200 servers, are you sure this is due to vse p6? we are now patching our servers from p4 to p6 and we will wait until it is clear. do you have HIPS P4 installed on these servers because it has issue with memory leak as explained by Mcafee below
Issue: A memory leak exists in the sqlserver.exe process with the Host IPS 8.0 SQL engine.
This issue is resolved in Host IPS 8.0 Patch 5, which is available by logging in to the ServicePortal at
I can only speak from what we have seen. Unfortunately, one of our engineers applied the VSE 8.8 Patch 6 to all our devices, without any testing? After the patch was deployed, we noticed most Hyper-V hosts were running out of memory. It took about 12-15 days for the memory to become critical, and when analysed the two McAfee processes, mferkdet.sys and mfehidk.sys, were consuming Gb of memory. To be honest, we are still investigating, but our initial tests do show that if the EPO agent and VirusScan are removed, the memory usage stabilises. We had to reboot the host servers, because they were becoming unusable. Because its a relatively slow leak, its going to take time to find the issue, the current plan is to use two or three hosts as a test, gradually re-introduce the McAfee components and policies, and try to identify the issue. It's worth saying that we had no issue with Agent 5.01 and VSE P5. We have a Support call in progress, I will keep this thread updated with what either ourselves or McAfee Support find.
Many thanks for your help, much appreciated. Sorry to miss-use the Communities for SR's, I posted because I was kinda hoping that we were no alone with this issue!
I will update the SR with the suggested data.