when debugging OOM bugs, what's the difference between working set and commit size? Especially what's the exact meaning for commit size?
Commit (KB). This is the total amount of physical and virtual memory (page file) that is committed to this specific process. Working Set (KB). This is the amount of physical memory that is committed to this particular process.
What is a Working Set? Working set is the physical memory assigned to a process by the Microsoft Windows NT and Windows 2000 operating systems. The working set consists of pages, which are sections of code and application data that have recently been used by the process.
The peak working set is a different thing. The working set is the amount of memory in a process (or, if you consider several processes, in all these processes) that is currently in physical memory. The peak working set is, consequently, the maximum value so far seen.
Commit size appears to be the actual amount of committed memory that is being used (either physical or page file). Commit charge is how much memory is committed (and therefore could come due at any time) but is not necessarily how much memory is currently allocated.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With