Environment.WorkingSet错误地报告内存使用情况 [英] Environment.WorkingSet incorrectly reports memory usage

问题描述

Environment.WorkingSet错误地报告为Windows 2003 Server上运行的网站上的内存使用情况（OS弗斯：微软的Windows NT 5.2.3790 Service Pack 2的.NET弗斯：2.0.50727.3607）。

据报道内存工作集（物理纪念品）：1952 MB（2047468061）

同一网站上的Windows Vista与工作组在本地运行（体育纪念品）：49 MB（51924992）

到服务器和支持

我很少有机会如此有限:(。
所以我必须通过VirtualQuery来遍历计算的总内存。
与国家总页数：mem_free已1300 MB。
（我猜的服务器有4个绿带的RAM和PAE未启用，最大用户模式虚拟地址是0x7fff0000。）

所以，我知道工作组不仅是虚拟内存。但是，它是正常的有这么高的工作集，而其非常低的另一台计算机上？

解决方案

我认为这个问题是关系到什么是的这篇文章：

  

2005年5月4日结果
  趣味的工作集和INT32 结果
  我终于找到一个诚实善良的bug在.NET框架。

  
  

在...
  工作集返回的内存量正在使用的过程
  一个整数（32位有符号整数）。 OK，这样的最大值
  整数是2,147,483,647 - 这是非常接近总
  内存量进程可在其工作集。

  
  

... ...有实际上是Windows中的一个开关，将允许一个进程使用
  3演出的记忆，而不是2演出。这个开关通常接通时
  处理分析服务 - 这个东西可以是一个记忆体猪。所以
  现在发生的事情是，当我轮询工作集，我得到一个负
  号，一个非常大的负数。通常，在境界
  -2,147,482,342。

  
  

...问题是溢出位。

  
  

工作集返回到一个二进制值.NET框架。该
  的整数的第一比特是符号位。 0为正，1为负。
  所以，当值从接通（二进制）
  1111111111111111111111111111111到（二进制）
  10000000000000000000000000000000值由2147483647进入
  -2147483647。

  
  

好了，我还是要解决这个问题。以下是我想出了（在C＃）：​​

 长lWorkingSet = 0;
如果（process.WorkingSet＆GT; = 0）
 lWorkingSet = processWorkingSet;
其他
 lWorkingSet =（（长）* int.MaxValue 2）+ process.WorkingSet;
 

  
  

希望这解决了这个问题现在。

  
  

真正的问题会在下山的路。微软<一个href=\"http://web.archive.org/web/20070214002249/http://blogs.msdn.com/brada/archive/2003/10/16/50535.aspx\"相对=nofollow>知道了解
  这个问题。我还是找出它们将如何解决这一问题的
  Win64的...其中这一招将不再工作。

---

  

http://msdn2.microsoft.com/library /0aayt1d0(en-us,vs.80).aspx ：结果
  还有的会是一个Process.WorkingSet64可变的，他们是
  德precating工作集。

  
  

在切线，不过，我认为这是不可能的，有管理的
  过程走近了3GB的限制，因为运行时拆分
  内存为多个堆。这是不是真的？

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?

解决方案

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?

这篇关于Environment.WorkingSet错误地报告内存使用情况的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！