39

when debugging OOM bugs, what's the difference between working set and commit size? Especially what's the exact meaning for commit size?

rogerdpack
  • 50,731
  • 31
  • 212
  • 332
user705414
  • 17,800
  • 36
  • 105
  • 151

1 Answers1

34

From here, the working set is:

... a count of physical memory (RAM) rather than virtual address space. It represents the subset of the process's virtual address space that is valid, meaning that it can be referenced without incurring a page fault.

The commit size is:

the total amount of pageable virtual address space for which no backing store is assigned other than the pagefile. On systems with a pagefile, it may be thought of as the maximum potential pagefile usage. On systems with no pagefile, it is still counted, but all such virtual address space must remain in physical memory (RAM) at all times.

So you can think of the working set as the amount of physical memory used, while the commit size indicates the amount of virtual memory used (sans things like DLLs or memory mapped files, which can be back by files other than the page file).

That said, these numbers are not generally useful when trying to find "memory leaks" in .NET. Instead, you should use third-party memory profilers.

Community
  • 1
  • 1
CodeNaked
  • 38,487
  • 6
  • 108
  • 141
  • 3
    Watching the .NET Memory performance counters will get you a long way to detecting a memory leak, before investing (if only learning time) in a profiler to identify what is leaking. – Richard Oct 31 '11 at 14:51
  • 1
    @Richard - That's true. There are also [free alternatives](http://blogs.msdn.com/b/delay/archive/2009/03/11/where-s-your-leak-at-using-windbg-sos-and-gcroot-to-diagnose-a-net-memory-leak.aspx) that can be useful. – CodeNaked Oct 31 '11 at 15:15
  • I think they're somewhat useful, at least if its a rather large leak, you should see it quite quickly :) – rogerdpack May 12 '16 at 22:14