非托管内存只能通过强制GC释放，但是为什么呢? [英] Unmanaged memory is only freed up by force GC, but why?

问题描述

我们有一个用WPF编写的复杂内部GUI应用程序.有时我们发现本机内存直到我们强制才释放 GC.Collect().这是我们在生产环境中收集的统计信息.

We have a complex internal GUI application written in WPF. Sometimes we find the native memory is not freed up until we force GC.Collect(). Here's the statistics we collect on production environment.

我们可以看到非托管内存有峰值，但是托管内存的使用率一直保持稳定.

We can see that there're spikes on unmanaged memory, but the managed memory usage stays lows and steady.

我知道GC仅在需要时才会发生，但是当有大量无人认领的不受管用户时，用户确实感觉很慢.当我们手动收集GC时，显然更快. GC之后可以释放非托管内存，因此我不认为这是内存泄漏.

I know GC will occurred only when required, but the user does feel slow when there're huge amount of unclaimed unmanaged. It's obviously faster when we collect GC manually. The unmanaged memory could be freed up after GC, so I don't think it's a memory leak.

我也想对如何识别过程中发生的事情有一些经验.我们有日志，并且已经从多个用户那里收集了多个具有相同问题的不同日志.不幸的是，我们未能从不同的地方找到相似之处 日志(看起来它将在任何时间发生并开始发生).

I also would like to have some experiences about how to identify what happens in the process. We have logs, and have collected several different logs with the same issue from multiple users. Unfortunately We failed to locate the similarity from different logs (look like it will happen and start happening in any time).

我们也无法在DEV或QA环境中重现该问题，或者我可以尝试使用DebugDiag来跟踪来自不同模块的非托管分配.顺便说一句，没有管理员权限，所以我无法跟踪非托管分配或设置全局 生产环境中的标志.

We cannot reproduce the issue in DEV or QA environment either, or I could try to use DebugDiag to trace the unmanaged allocation from different modules. BTW, there's no administrator privilege, so I cannot trace unmanaged allocation or setting up global flags in production environment.

但是我们可以进行全内存转储-是否有助于识别问题(以及如何解决)?

But we can do full memory dump - does it help to identify the issue (and how)?

快乐编程，快乐生活.
http://blog.zhaojie.me/

Happy programming, happy life.
http://blog.zhaojie.me/

推荐答案

我觉得很奇怪，您遇到了一个无法在dev中重现的问题.

I find it rather odd that you have an issue live that you can't reproduce in dev.

该代码将在开发人员或现场进行相同的工作.

The code will do the same thing in dev or live.

不同之处在于您使用该应用程序的方式.

The difference is how you use the app.

意味着您的用户正在做一些不同的事情.最好的选择是找出问题所在并重现问题.

Meaning your users are doing something different. Your best bet is to work out what that is and reproduce the problem.

您可能已经知道.

如果您无法重现问题，那么解决该问题将是一个问题.

If you can't reproduce a problem then fixing it is going to be a problem.

.

我建议您查看用户可能在做什么，并查看是否可以重现该问题.

I suggest you take a look at what the user might be doing different and see if you can reproduce the issue.

我还将获得ant内存分析器的免费试用版:

I would also get a free trial copy of ants memory profiler:

http://www.red-gate.com/products/dotnet- development/ants-memory-profiler/

以此运行您的应用程序，然后查看它的功能.到目前为止，蚂蚁是这类问题跟踪工具中最好的.如果您的应用程序很复杂，我会考虑购买一个副本.我用它来查找数字上的问题.

Run your app by that and see what it comes up with. Ants is by far the best of these sort of problem tracking tools. I would consider buying a copy if your app is complex. I've used it to track down problems on a number.

.

如果仅获得内存转储，则将很难使用.如果您正在使用互操作或类似功能，则您可能会注意到Excel拥有很大的内存，但否则必须真幸运.

If you just get a memory dump then it'll be very difficult to work with. I you're using interop or something similar then you might notice Excel has a huge chunk of memory but otherwise you'd have to be pretty lucky.

 

这篇关于非托管内存只能通过强制GC释放，但是为什么呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！