C# 内存碎片？

我不确定，因为我在分析内存转储方面没有太多经验，但我认为我们可能在内存碎片方面有问题

在负载测试期间，我们看到内存使用量正在增长到应用程序重新启动的程度。 它是64位机器上的ASP.NET MVC 4应用程序。我没有参与写作。我只是被要求尝试分析内存转储

因此，在上一次负载测试期间，我们创建了3个内存转储（低于它们的大小和eeheap-GC输出的总GC堆大小）：

1.70GB，292MB

2.03GB，337MB

2.55GB，347MB

所以，正如您所看到的，托管堆的增长不如转储文件。 当我执行dumpheap-stat时，我看到大部分空间被空闲对象使用（下面是每个转储文件）

147MB

145MB

213MB

大于0.5 MB的碎片块： 地址大小后跟 000000 BCC668E0A8 0.7MB 000000 BCC6738650系统。对象[] 000000 BCC6949F88 4.4MB 000000 BCC6DAB820 System.Collections.Specialized.NameObjectCollectionBase+NameObjectEntry 000000 BD4626C4B8 0.7MB 000000 BD463165F8系统。字节[] 000000 BD463FCC48 51.5MB 000000 BD4977BAF0 System.Threading.ThreadStart 000000 BE463600C8 0.7MB 000000 BE464108F0免费 000000 BEC67E50E0 1.1MB 000000 BEC690B020 System.Collections.Generic.List`1[[OurType，ANotherOurType]] 000000 BEC690B0B8 3.2MB 000000 BEC6C3B170系统。字节[] 000000 BFC6605E00 1.0MB 000000 BFC6710190免费 000000 BFC6743C58 32.8MB 000000 BFC8806FE8 System.Threading.ExecutionContext 000000 C046200580 1.0MB 000000 C0462FF2A0某种类型 000000 C0463A1270 3.6MB 000000 C046732AC0 Microsoft.Win32.SafeHandles.SafeCapiKeyHandle 据我所知，在所有堆大小中，当空闲对象只占内存总量的一小部分时，这并不是问题。这看起来是个问题

应用程序正在使用两个外部库。一个用于创建PDF-s，另一个用于创建条形码文件。条形码库正在抛出AccessViolationException（2200次尝试大约70次）。它抛出了这个stacktrace

System.AccessViolationException:尝试读取或写入受保护内存。这通常表示其他内存已损坏。
at System.Drawing.SafeNativeMethods.Gdip.IntGdipDeleteGraphics（HandleRef图形）
at System.Drawing.Graphics.Dispose（布尔处理）
在System.Drawing.Graphics.Dispose（）中
在Lesnikowski.Barcode.BaseBarcode.Render（）中
在Lesnikowski.Barcode.BaseBarcode.Save（流、ImageType、ImageType）

我读到过，内存碎片通常是由固定内存引起的，但这是真的！GCD处理输出

Handles: Strong Handles: 154 Pinned Handles: 23 Ref Count Handles: 2 Weak Long Handles: 1794 Weak Short Handles: 74 SizedRef Handles: 17 Dependent Handles: 1 处理： 强句柄：154 销柄：23 引用计数句柄：2 弱长手柄：1794 弱短柄：74 SizedRef句柄：17 依赖句柄：1 我不知道还能查到什么。我们有内存碎片问题吗？ 你能给我指个方向吗

编辑： 我附加负载测试期间收集的性能计数器。很奇怪，因为它显示了很多被钉住的物体，但是！没有显示它们

red line - user load green line - bytes in all heaps blue line - pinned objects

红线-用户负载 绿线-所有堆中的字节 蓝线-固定对象 编辑2：

---

添加了大于0.5 MB的碎片块：输出自！dumpheap-stat

您应该使用

！address-summary

了解此过程中虚拟内存的使用情况。尽管看起来有一些堆碎片，但在您的进程中很可能还有一些额外的重内存消耗。它可能是Win32堆，可能是线程堆栈，可能是动态加载的程序集，等等

---

对于每种类型的泄漏，您必须遵循稍微不同的方法。对于Win32堆检查，您应该使用

的变体！堆

命令-

！堆-统计

，

！heap-s-h0

。对于程序集加载问题，您应该使用

查看加载程序堆！eeheap-loader

，然后使用

检查您拥有的各种AppDomain！dumpdomain

以查看正在加载的程序集。这些只是一些示例-您必须提供有关您的情况的更多详细信息。

内存碎片可能导致OOM；然而，这看起来像是一个普通的BCL错误-这不应该以这种方式出错，不管是不是零碎的。你是说那些AccessViolationException？这可能是BCL或我们的条形码库错误。但我不确定它是否以任何方式连接到内存转储。谢谢。我想我已经找到了“内存泄漏”。这是LOH碎片。没有时间更新问题/为我自己的问题提供答案。@PiotrPerak你能给我指一些性能计数器吗？这些计数器可以帮助检测碎片的发生？ Handles: Strong Handles: 154 Pinned Handles: 23 Ref Count Handles: 2 Weak Long Handles: 1794 Weak Short Handles: 74 SizedRef Handles: 17 Dependent Handles: 1 red line - user load green line - bytes in all heaps blue line - pinned objects