Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a 16 GB Windows Server 2008 x64 machine mostly running SQL Server 2008. The free memory as seen in Task Manager is very low (128 MB at the moment), i.e. about 15.7 GB are used. So far, so good.

Now when I try to narrow down the process(es) using the most memory I get confused: None of the processes have more than 200MB Working Set Size as displayed in the 'Processes' tab of Task Manager. Well, maybe the Working Set Size isn't the relevant counter?

To figure that out I used a PowerShell command [1] to sum up each individual property of the process object in sort of a brute force approach - surely one of them must add up to the 15.7 GB, right? Turns out none of them does, with the closest being VirtualMemorySize (around 12.7 GB) and PeakVirtualMemorySize (around 14.7 GB). WTF?

To put it another way: Which of the numerous memory related process information is the "correct" one, i.e. counts towards the server's physical memory as displayed in the Task Manager's 'Performance' tab?

Thank you all!

[1] $erroractionpreference="silentlycontinue"; get-process | gm | where-object {$.membertype -eq "Property"} | foreach-object {$.name; (get-process | measure-object -sum $ ).sum / 1MB}

share|improve this question

Adding up the memory usage of all processes will not generally produce meaningful results. That will leave two major users of memory unaccounted for, the system cache and the standby list. You cannot account for memory usage by simply adding up a list of numbers. The memory management system is far too complex for that.

share|improve this answer
"The memory management system is far too complex for that." - you're right about that... I now resorted to reading the "Memory Management" Chapter from Windows Internals, 4th ed. and I now understand I was seeing things too simplistically... – Sleepless May 10 '10 at 10:17

Adding up working sets also multi-counts pages that are shared across processes, like code from system DLLs and executables started more than once.

share|improve this answer

SQL-Server uses on 64-bit AWE for locking the memory-pages and the amount is not counted in taskmanagers "The Working Set".

share|improve this answer
ah - no, it does not. Not if the SQL Server is 64 bit installed, and seriously only someone challenged with the basics would install a 32 bit SQL Servre on a 64 bit OS. I rather assume this is a 64 bit SQL Server, which does not use AWE. – TomTom May 7 '10 at 16:54
"3 Note that the sp_configure awe enabled option is present on 64-bit SQL Server, but it is ignored. It is subject to removal in future releases or service packs of 64-bit SQL Server." Seen on: [] So i was wrong, sorry. – Ice Jun 11 '11 at 11:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.