Question

Environment.WorkingSet incorrectly reports the memory usage for a web site that runs on Windows 2003 Server.(OS Vers: Microsoft Windows NT 5.2.3790 Service Pack 2, .NET Vers: 2.0.50727.3607)

It reports memory as Working Set(Physical Mem.): 1952 MB (2047468061).

Same web site runs locally on Windows Vista with a Working Set(Physical Mem.): 49 MB (51924992).

I have limited access to the server and support is so limited :(.
so i have computed the total memory by traversing with VirtualQuery.
Total of pages with state: MEM_FREE is 1300 MB.
(I guess server have 4 GBs of RAM and PAE is not enabled, max user mode virtual address is 0x7fff0000.)

So, i know working set is not only about virtual memory. But, is it normal to have such a high working set while its very low on another machine?

Answer 1

I think the problem is related to what is described in this article:

MAY 04, 2005
Fun with the WorkingSet and int32
I finally found an honest to goodness bug in the .NET framework.

… the
WorkingSet returns the amount of memory being used by the process as
an integer (32 bit signed integer). OK, so the maximum value of an
integer is 2,147,483,647 — which is remarkably close to the total
amount of memory that a process can have in its working set.

… There is actually a switch in Windows that will allow a process to use
3 gig of memory instead of 2 gig. This switch is often turned on when
dealing with Analysis Services — this thing can be a memory hog. So
now what happens is that when I poll the WorkingSet I get a negative
number, a really big negative number. Usually, in the realm of
-2,147,482,342.

… The problem was the overflow bit.

Working set is returned to the .NET framework as a binary value. The
first bit of an integer is the sign bit. 0 is positive, 1 is negative.
So, when the value turned from (binary)
1111111111111111111111111111111 to (binary)
10000000000000000000000000000000 the value goes from 2147483647 to
-2147483647.

OK, so I still have to fix this. Here is what I came up with (in C#):

long lWorkingSet = 0;
if (process.WorkingSet >= 0)
 lWorkingSet = processWorkingSet;
else
 lWorkingSet = ((long)int.MaxValue*2)+process.WorkingSet;

Hopefully that fixes the problem for now.

The real question will come in down the road. Microsoft knows about
this problem. I still have find out how they are going to fix this for
Win64…where this trick will no longer work.

---

http://msdn2.microsoft.com/library/0aayt1d0(en-us,vs.80).aspx:
There’s gonna be a Process.WorkingSet64 variable, and they’re
deprecating WorkingSet.

On a tangent, though, I thought it was impossible for a managed
process to come near the 3gb limit, because the runtime splits the
memory into multiple heaps. Is this not true?