查找 Windows 应用程序的真实内存占用量
我的 C#/WPF 应用程序遇到了一些 OutOfMemoryExceptions，并且在尝试分析内存使用情况时遇到了一些令人困惑的数据。
当应用程序通常运行时，Windows 任务管理器显示内存使用量约为 34 MB（在创建对象和垃圾收集时略有波动）。当我运行内存分析应用程序时，例如 CLR Profiler 和 dotTrace Memory，它们显示总内存使用量约为 1.2 MB。
为什么会有如此巨大的差异？任务管理器能看到哪些分析器没有看到的内容？
更新：我在应用程序中添加了一些诊断代码，以便经常通过 Process 类打印出各种内存信息。
运行我的应用程序时，我在 DebugDiag 在发生异常时执行内存转储。我强制抛出异常并发生内存转储。此时，我的应用程序的内存使用量（如任务管理器所示）从 32 MB 跃升至 145 MB，并保持不变。
您可以在下表 (WorkingSet64) 中看到此跳转。我仍在尝试理解 Process 类提供的所有类型的内存信息。外部应用程序如何使我的应用程序的工作集像这样增长？
I've run into a few OutOfMemoryExceptions with my C#/WPF application and I'm running into some confusing data while attempting to profile the memory usage.
When the app is typically running, Windows Task Manager shows the memory usage as somewhere around 34 MB (bounces around slightly as objects are created and garbage collected). When I run memory profiling applications such as CLR Profiler and dotTrace Memory, they show the total memory usage at around 1.2 MB.
Why this huge discrepancy? What does Task Manager see that these profilers do not?
UPDATE: I added some diag code to my application to print out various memory information every so often via the Process class.
While running my app, I set up a rule in DebugDiag to perform a memory dump in the event of an exception. I forced an exception and the memory dump occurred. At this point, the memory usage of my app (as shown by task manager) jumped from 32 MB to 145 MB and remained there.
You can see this jump in the table below (WorkingSet64). I'm still trying to make sense of all the types of memory info provided by the Process class. How would an external application make the working set of my app grow like this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用此处建议的一些诊断工具以及 ANTS 内存profiler（太有钱了）我找到了泄漏的源头。
内存分析工具帮助我发现泄漏主要发生在非托管代码中，这使得追踪变得非常痛苦。处理这些泄漏，再加上对 Windows 内存（私有内存与工作集）的更好理解，问题就解决了。
Using some of the diagnostics tools suggested here, plus the ANTS memory profiler (which is so money) I found the source of the leak.
The memory profiling tools helped me find that the leaks were mostly in unmanaged code, which made it a real pain to track down. Dealing with these leaks, plus a better understanding of Windows memory (private vs working set) cleared things up.
流程浏览器 和 VMMap，都是 Sysinternals Suite，作者：Mark Russinovich。
Prcess Explorer and VMMap, both part of the Sysinternals Suite by Mark Russinovich.