Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

On our Windows 2008 R2 64 bit servers there seems to be a discrepancy between the number shown in Task Manager on the Performance tab in the Memory Graph and the sum of the Memory (Private Working Set) on the Processes tab. The former is consistently higher. The discrepancy does not seem to depend on the amount of memory allocated to the box or on the number of processes on the box. For the four servers I have examined the discrepancy ranged from 853 MB to 4,178 MB. Can someone please explain this?

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

In addition to process private working sets, there are many other types of memory that contribute to the total memory usage, such as kernel allocations, pages mapped into the system cache working set, pages on the modified list etc. You can use RamMap.exe (http://technet.microsoft.com/en-us/sysinternals/ff700229.aspx) to get a more detailed picture of what's actually in memory.

share|improve this answer
    
This led me to see that Nonpaged Pool memory is using 2.4 GB, which in turn led me to poolmon.exe to determine what is using Nonpaged Pool memory. The top four consumers have tags of File, IoNm, Ntfc, and CcPc, so I am going to try figure out why those are so high. –  Leigh Riffel Nov 22 '10 at 16:52
    
Those are “File Objects”, “Io parsing names”, “NTFS Specific CCB_DATA” and “Cache Manager Private Cache Map”. So I know what they are, but still have no idea why they are using more memory than normal. –  Leigh Riffel Nov 22 '10 at 20:30
add comment

The "memory" graph in Task Manager is the amount of total physical memory in your machine, minus the available physical memory.

The process working set counter also looks at physical memory - but shared DLLs which only use one physical memory location are counted toward the working set of each process that uses it - therefore, the working set overcounts memory.

If a process pages memory out to disk, this is not included in the working set counter, and can therefore cause the working set to undercount the amount of memory used.

Here is a listing of what all of the counters map to: http://msdn.microsoft.com/en-us/library/aa965225(VS.85).aspx

And here is a pretty good blog post that goes into some details: http://www.itwriting.com/dotnetmem.php

share|improve this answer
    
This is the exact opposite of what I am seeing. See the text in bold. –  Leigh Riffel Nov 19 '10 at 22:02
    
@Leigh: updated to include possible reason for undercounts. See the 3rd paragraph under the graphic in the blog post. –  MattB Nov 19 '10 at 22:08
    
Thanks for the update, but that explanation does not seem adequate. On systems with 10+GB of free memory and only 2111 MB listed in the processes list the graph is showing 4.49 GB in use, which would mean that more memory was being paged to disk than the total amount shown for all processes on the box. If this were just one system I would count it as a fluke, but I've seen it on all five I've looked at so far. –  Leigh Riffel Nov 19 '10 at 22:34
add comment

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.