Sql-server – Windows Server 2008 R2 64-bit memory leak

cachememorysql servervirtual-machineswindows-server-2008

I´m having trouble in one of my office servers. It´s a virtualized Windows 2008 R2 Server with 6GB RAM memory. It only has Microsoft SQL Server (memory assigned maximum = 3GB), and just a software that is not consuming more than 1GB RAM.
However, server´s RAM memory is almost full, and looking at the processes in task manager they doesn´t seem to sum this. I have installed RamMap, but cannot interpretate it very easily, is there any "high value" you can identiy?

enter image description here

Best Answer

Well, I see ~3.2 gigabytes of Driver Locked memory, which immediately stands out as suspicious.

This kind of memory, Driver Locked memory, is memory that has been locked by a kernel-mode driver. Typically for the purpose of transferring small amounts of data, usually for short periods of time.

So if you have a large chunk of driver locked memory, for a long time, it's usually a sign that something's not right.

I'm going to take a wild guess here and guess that since you mentioned that it's a virtualized server, that it's the VMware balloon driver that's doing this. I don't have enough data to be able to tell you why it's doing this, but there are plenty of cases and VMware support KBs, like this one, that specifically talk about the balloon driver erroneously retaining large amounts of memory when it shouldn't be.

You also have to consider the possibility that the balloon driver is behaving as designed, and it's trying to make your server page out memory because it desperately needs to give memory to another VM on the same host.

There is yet another possibility that it is not a hypervisor dynamic memory driver at all, but instead just some rogue device driver.

Drivers usually allocate memory that is "tagged" with a 3 or 4-character tag that gives a hint as to what driver was responsible for making the allocation.
poolmon.exe, part of the Windows SDK/DDK, can help diagnose.

Like I said, wild guess, but it's the best I can do with the data I have.