If you're doing memory scans this is expected behavior.
Trimming the working set is necessary after we're done with scanning the process, otherwise you'd be escalating a different problem - saying, McAfee is causing the working set of processes to grow... which we do, of course, but we didn't used to initiate a Trim afterwards.
If data is lost in any particular process as a result of the memory manager APIs being issued, it's not something we can solve. Memory management is intrinsic to the operating system. If issues are occurring as a result, then it's good to bring them to our attention but expect the solution to be "avoid memory scans" or "take it up with Microsoft" or "we can submit a product enhancement request to allow excluding of processes from memory scanning" (which is the best outcome by my reckoning).
But in your case there are no errors or lost data, it's just a warning message. If you know the cause is our memory scan, one might conclude it's safe to ignore.
Thank you for the tip. I just wanted to verify that you are talking about the Processes on enable checkbox in EPO under On-Access General policies. If so, I will try disabling for my SQL servers.
Unfortunately, I know it is AV causing the issue. As it started the day after I upgraded to 8.8 from 8.7 and it happens on every DAT update since. I've disabled AV on one of my SQL boxes and the warning went away. On that same box, I watched a SQL instance with 15GB RAM (Working Set) drop to about 500MB. Needless to say, the server was adversely affected. (Which pushes it beyond a warning to you have major peformance problems.)
The exclusion of processes from memory scanning sounds like a great addition to the product because what you say makes a lot of sense and that's where I was leaning after I eliminated the file cache from being the culprit.
Thanks again for the information and after I verify this fixes it I'll rush back and mark this Corrected.
We are also experiencing this same problem. I tried the fix that you mentioned Slyfin but it didn't stop the memory trim (flush) from occuring after the DAT update. I too have put in an SR and will report back on the results.
1 of 1 people found this helpful
Sorry I either forgot to answer the thread or my response was removed due to inapporiate content.
You get to choose your poison.
A. Downgrade to 8.7 and stay there as long as you can.
B. Configure your SQL server so you can use Lock pages in Memory. SQL 2k5 SP3 CU4 or higher adds lock pages in memory support even for Standard edition. There is a Microsoft KB article to configure it but this page sums it up nicely.
<self censored long winded comments go here>
I had to open a ticket with Microsoft because they felt it's a SQL problem that was illuminated by McAfee 8.8. Thus not a problem for McAfee support but I hope your SR goes better than mine.
Wow, thanks McAfee for finding that "bug" in SQL lol.
I'm glad that Microsoft finally allowed the standard versions of SQL to use the lock pages in memory feature. All the reading I had done on this problem said that could solve it but only for enterprise versions. Have you implemented this change and has it solved the memory flush problem?
Actually, I downgraded to 8.7 Patch 4.
In limited testing it seemed to work. I didn't proceed for a few reasons.
1) I wasn't running a CU/SP level that will enable the option. I've had problems with CUs in the past and I recently started testing 2k5 SP4.
2) I really don't like the warning about "this may have a negative performance impact on your system." In my mind trading one issue for another isn't a fix.
3) Some of my systems are running up to four instances. So locking pages in memory leads to a lot of memory configuration testing and tweaking.
4) I haven't had the time or the willpower to properly test this. Once they set an EOL date for 8.7 I I'll have to reevaluate.
today we have a customer where this problem occurs (VSE 8.8 with P2 and the latest Hotfixes). Are there any new informations available about this?
A few months ago, I found https://kc.mcafee.com/corporate/index?page=content&id=KB76157 Following the "you may choose to disable these VSE features" part. I opened a SR asking how to disable. Support wanted me to reproduce the issue before providing anything helpful. My test servers didn't have enough of a load to do this and I was/am reluctant to start upgrading my production systems. (Even more so now that I see another person is having issues.) So I had them close the ticket and I started planning for a VERY slow 8.8 rollout. With 8.8 patch 4 so far out on the horizon, I may be sticking with 8.7 patch 4 and the 5400 scan engine until early next year.
If I hit the bug again, I'm not sure what I plan to do. Neither option seems palatable. Open up another SR or harden the system/remove McAfee
I was able to solve this issue by following the steps that Slyfin posted above:
I was a little nervous about doing it but I haven't experienced any adverse side effects for the past 1.5 years.
In addition to enabling the lock pages in memory feature I also adjusted the "Maximum server memory" setting to prevent SQL from consuming too much RAM. My server has 24GB of RAM so I limited SQL to 16GB and it's been performing flawlessly. There may be a more precise way to figure out the optimal settings but I figured leaving 8GB for Windows would be sufficient. If you aren't sure what setting I'm talking about go in the SQL Server Management Studio, Right-click your server at the top of the tree and select Properties. Then switch to the Memory page and you will see the min and max server memory settings. I left the min setting at it's default of 0.
Hope this helps!