1

I'm trying to monitor memory usage. I wrote a sample c# code to be certain that I'm measuring correctly:

var list = new List<byte[]>();
int INCREMENT = 100; // 100MB
for(int i=0; i<10; i++){
  list.Add(new byte[INCREMENT * 1024 * 1024]);// 100 MB steps
  Thread.sleep(4000);
}

I used task manager and recorded the readings for "Private Working Set":

3'800k = 3.7M
3'900k = 3.8M
4'100k = 4M
4'300k = 4.2M
4'500k = 4.4M
5'200k = 5.07M
5'400k = 5.27M
5'600k = 5.47M
5'900k = 5.76M
6'100k = 5.96M

Does anyone know why the numbers make no sense?

max
  • 9,708
  • 15
  • 89
  • 144

3 Answers3

1

Instead of looking at "Memory (Private Working Set)", look at "Commit Size". You may have to add it with "/View/Select Columns..." then check "Commit Size". For me it increased by about a GB, while working set went up by 3 MB.

Spizmar
  • 34
  • 2
  • 2
    Just to add to this, try looking at [this page](http://windows.microsoft.com/en-us/windows/what-task-manager-memory-columns-mean#1TC=windows-7) for an explaination of what these things mean. Also, try looking at this [SO Question](http://stackoverflow.com/questions/31096/process-memory-size-different-counters) in which Lars does a good job explaining what these things mean in better English. – Icemanind Apr 18 '14 at 22:30
  • Thanks. What's called "Commit size" in task manager is the one that makes sense. Now, I'm trying to retrieve it from wmi, but the Win32_PerfRawData_PerfProc_Process class does not have such a property. The Win32_PerfRawData_PerfOS_Memory class has such a property, but it is a global value - not process specific. Any ideas? see: http://msdn.microsoft.com/en-us/library/aa394323(v=vs.85).aspx – max Apr 19 '14 at 01:02
  • from Icemanind's link, Memory-Commit Size is the same as Virtual Memory. But when I monitor VirtualBytes with wmi, it does not change. – max Apr 19 '14 at 01:11
1

If you look at the definition for "Memory (private working set)" in Task Manager, it says "Amount of physical memory in use by the process that cannot be used by other processes". This is very different from "private bytes" which is the number of virtual memory bytes that cannot be shared by other processes.

The data you allocate in your sample may or may not be backed by physical memory at any given time. That's what is reflected by "Memory (private working set)". Since you never write any of that memory Windows has cleverly decided not to back the virtual memory with real memory pages. If you fill the array with data you'll see that the corresponding memory pages are allocated.

Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317
  • Your comment makes sense. My goal here is to use wmi to detect memory issues and I guess that unallocated (virtual) memory is a potential problem as well and would be nice to monitor. Do you agree? – max Apr 19 '14 at 01:37
  • I'm not sure what you mean. The point here is that when you allocate memory in your example, the memory is reserved, but not committed which is why you don't see the expected increase reported by task manager. If/when you write the memory it is committed and thus you'll see that reflected in the number reported by task manager. – Brian Rasmussen Apr 19 '14 at 02:42
0

When I run the code posted above, I actually see the "commit size" in task manager increase. If I want to retrieve that in a sript, I need to use the wmi api. When I use a wmi query such as this:

SELECT PrivateBytes FROM Win32_PerfRawData_PerfProc_Process WHERE IDProcess=1234

it does not detect the increase. You can run this query either in powershell, python,...while the test app is running. I appreciate if someone can comment on this as well.

max
  • 9,708
  • 15
  • 89
  • 144