PeakWorkingSet64，没有给我正确的结果答案

【问题标题】：PeakWorkingSet64, doesn't give me the proper resultPeakWorkingSet64，没有给我正确的结果
【发布时间】：2011-10-22 04:50:06
【问题描述】：

我正在使用 System.Diagnostics.Process。 PeakWorkingSet64 获取当前进程的内存使用情况。这个过程可以达到8、10甚至12GB（不要问）。我的问题是，当我查询进程 PeakWorkingSet64 时，它工作正常，直到它停留在 4096mb。

我的代码是：

p.Refresh();

int m = (int)(p.PeakWorkingSet64 /(float) 1024 /(float) 1024);

如有任何帮助，将不胜感激

【问题讨论】：

我知道你说过不要问，但 12GM 是什么？你对 12GM 的 m 有什么期望？
你有多少物理内存？
12gm 是一个错误 - 将其修复为 12gb
它是否上升到 4096 并停止，即它是否曾经报告超过 4096？
No 从不，即使任务管理器报告更多

标签： .net memory

【解决方案1】：

在黑暗中拍摄...

您的最大容量为 4GB，但您有 24GB 的物理内存。 4GB 是 32 位进程在 64 位 Windows 操作系统上拥有的最大用户地址空间量。尝试将程序显式地作为 64 位进程运行。我的预感是它作为 32 位进程运行。

VS：项目属性 -> 构建 -> 平台目标：x64

更新

将我的平台设置为 x64 后，我系统上的以下代码超过了 4GB 的工作集。当我在具有 6GB 内存的系统上进行测试时，它并没有超过这个值，而且没有足够的内存超过 ~ 4.2GB。我确实有一台内存为 24GB 的服务器，但我不愿意为这个测试使用它！ :)

当你说你的程序在你的系统上看到 12GB 内存使用量时，我猜你的评论是总的虚拟内存使用量，而不是物理内存用法。 PeakWorkingSet64 指的是物理内存。

我在代码中放置了一些小技巧，以确保生成的数据被触及，以使其保持热状态并在物理内存中并且不会被分页（分页内存不包括在工作集图中，因为它在页面文件，而不是在实际的物理内存中）。如果没有被触摸，Windows 会主动将内存分页到磁盘。

        Console.WriteLine("Is64=" + (Marshal.SizeOf(IntPtr.Zero) == 8));

        Process p = Process.GetCurrentProcess();

        List<int[]> data = new List<int[]>();

        while (true)
        {
            int[] buffer = new int[1024 * 1024 * 128]; //<- 0.5GB

            data.Add(buffer);

            int touch = 0;

            foreach (var b in data)
            {
                for (int i = 0; i < b.Length; i++)
                {
                    touch += b[i];
                }
            }

            p.Refresh();

            int mb = (int)(p.PeakWorkingSet64 / (float)1024 / 1024);

            Console.WriteLine("ignore" + touch);

            Console.WriteLine(mb + "MB");

            Thread.Sleep(1 * 1000);
        }

输出：

忽略0
524MB
忽略0
1055MB
忽略0
1560MB
忽略0
2074MB
忽略0
2587MB
忽略0
3101MB
忽略0
3615MB
忽略0
4132MB
忽略0
4188MB

重要提示

确保使用 PeekWorkingSet64 的进程是 64 位进程。令我惊讶的是，尝试获取另一个 64 位进程的 PeekWorkingSet64 的 32 位进程将仅获得 4096MB 作为其最大内存使用量，即使受监控的进程是 64 位并且拥有比这更多的物理内存。

【讨论】：

+1：是的，这也是我的猜测。但是，OP 表示进程可以达到 8 到 12 GB。如果这从未发生过，而只是一个估计，那么是的，这是一个很好的选择。
@Christian 我假设 OP 看到 8 GB 和 12GB 的虚拟内存，而 PeakWorkingSet64 返回 physical 内存。
但是对于 32 位进程，虚拟内存会有相同的限制 (~4GB)，不是吗？
@Christian 你的想法是对的——现在我很困惑！不确定 12GB 来自哪里，4GB 将是总可用地址空间。我已删除我的编辑。
不用担心，鉴于可用的信息，它仍然是最有可能的答案。 ;-)

【解决方案2】：

工作集是应用程序实际可见的物理内存量。 Windows 一直在从所有正在运行的进程中窃取页面。它会在它们上面停留一段时间，如果你试图访问它们，你就会把它们找回来（这被称为软故障）。

如果其他人需要内存，您的页面将被写入交换文件、归零并重复使用。

因此，您的应用程序使用的物理内存可能大于工作集。窗口“借用”的页面不计算在内。

Windows 对工作集有每个进程的限制。对于 32 位应用程序，这是 1.3gb。您可以在进程资源管理器中查询。也许对于 64 位，这个值是 4gb，我不知道。对于您描述的过程，提高此限制可能是值得的，因此 Windows 停止尝试修剪您的进程内存占用。

如果你想控制你的内存使用，你想看看你的进程使用的总虚拟内存。

【讨论】：