问题标签 [large-object-heap]

这个问题是Efficient way to transfer many binary files into SQL Server database的后续问题

我最初问为什么 usingFile.ReadAllBytes会导致快速的内存使用，并得出结论使用该方法将数据放在大型对象堆上，在运行时不容易回收。

我现在的问题是如何避免这种情况？

以下代码旨在通过分块读取文件而不是一次读取文件来解决该问题，但它似乎有同样的问题。

从阅读二进制文件时避免 LOH跟进

在 Nhibernate 中是否可以将一个Stream块保存到数据库中？

使用以下代码，打开 FileStream 并以 2kb 的块读取其内容：

通常对象在一个操作中被持久化，可以增量完成吗？

我们的 IIS 6.0 应用程序池在第一次加载 155Mb 内存页面时占用。在随后刷新同一页面时，消耗的应用程序池内存上升到大约 245Mb。

它是一个网络表单应用程序，使用实体框架和 DevExpress 控件。

起初我认为这是内存泄漏，但在使用内存分析器进行进一步调查后发现，应用程序池占用的空间中有一半以上是可用空间，但却是碎片化的。

这将矛头指向了大对象堆内存碎片作为罪魁祸首。确实有一个大约 980Kb 的长列表，这通常会导致碎片，尤其是当列表增长和调整大小时会在内存中留下漏洞。

所以我创建了一个复合列表，基本上是一个列表列表，其想法是因为每个列表都小于 85000 字节，它会被分配到在垃圾回收后被压缩的普通堆中（不像大对象堆，它永远不会被压实）

预计复合列表会像其他地方一样使用列表来确保对象逃离大对象堆，但在这种情况下它似乎没有任何真正的区别，并且应用程序池内存是仍然在 240Mb 左右，而内存分析器报告点网 CLR 内存在 10Mb 左右。

我计划进行内存转储以查看发生了什么，但只是想知道是否有人对可能的原因有看法。

我有一个应用程序需要通过 http 大量（>10k）下载大型 xml 文件（8-10MB），使用一个 xpath 表达式在其中获取一些内容。

我想知道如何优化这个过程。这些 xml 文件将直接进入大对象堆。我正在考虑三个选项： - 整体优化：使用单独的 IO 线程池下载 xml 文件 - 使用流来读取带有 xml 文件的 Web 响应，而不是读入将转到 LOH 的字符串（不确定是否可能以及如何这样做那） - 使用正则表达式从 XML 检索内容，因为 XPath 非常简单，我不需要完整的 DOM 支持。

还有其他选择吗？

我正在使用一个系统，该系统具有包含超过 500 万个项目的列表和字典，其中每个项目通常是具有多达 90 个原始属性的平面 dto。使用 protobuf-net 将集合持久保存到磁盘以进行弹性和子序列处理。

不出所料，我们在处理和序列化过程中遇到了 LOH。

我们可以通过使用 ConcurrentBag 等来避免处理过程中的 LOH，但是在序列化时我们仍然会遇到问题。

目前，集合中的项目被分批成 1000 个组并并行序列化到内存流中。每个字节数组都放置在并发队列中，以便稍后写入文件流。

虽然我理解这是试图做什么，但它似乎过于复杂。感觉 protobuf 本身应该有一些东西可以在不使用 LOH 的情况下处理大量集合。

我希望我犯了一个小学生的错误——我忽略了一些设置。否则，我将寻找编写自定义二进制读取器/写入器。

我应该指出，我们正在使用 4.0，希望尽快迁移到 4.5，但意识到尽管 GC 有所改进，但我们无法克服这个问题。

任何帮助表示赞赏。

我正在尝试将带有 HTTPWebRequest的大文件（大约 30MB ）的字节上传到某个服务器。问题是由于字节大小超过85000，它被存储在LargeObjectHeap ( LOH ) 中。问题是我的代码在 LOH 中创建了至少 5 个相同对象的实例，即使在关闭响应流之后也没有从内存中删除。以下是导致此问题的代码片段。在此代码块之前，LOH 中只有一个文件实例。

有没有办法进一步优化这个代码块，以便在堆中创建更少的副本。

在 .net 4.5 中，CLR 团队有StringBuilder很多变化。这是StringBuilder类的代码参考。在这里，我们可以找到MaxChunkSize等于 8000 并在此字段上方进行注释：

所以我仍然想知道，我们是否会使用StringBuilder附加大字符串，例如：

我们还会在 LargeObjectHeap 中分配 ChunksArrays 吗？

当我尝试返回 30 MB 的大数据时（此范围可以达到 GB），Web API 控制器操作会引发 OutOfMemory 异常。任何人都知道我如何才能摆脱这个问题，或者就如何将大型对象图发送回客户端提出任何替代方案？

我正在尝试调试旧网站中 CPU 使用率高的原因，并且通过查看 DebugDiag 中的一些分析，我怀疑 LOH 上的对象数量以及随后的 GC 收集可能是一个原因。在一个 .dbg 文件中，我们在 LOH 上有约 3.5gb，其中大部分对象是字符串。

我知道，要在 LOH 上运行的对象，它们必须超过 85000 字节。

我不确定这是否是指例如单个数组。或者它可以引用一个大对象图吗？

我的意思是如果我有对象 Foo，它包含 n 个其他对象，每个对象本身都包含 n 个对象。如果这些对象中的每一个都包含字符串，并且 Foo（和所有子对象）的总大小大于 85000 字节，是否会将 Foo 放置在 LOH 上？或者，如果在 Foo 对象图中的某个地方有一个大于 85000 字节的数组，那么它是否只是放置在 LOH 上的那个数组？

谢谢。

我们在 Server 2012 上有一个使用 WebApi 2 和 .NET 4.5 的 Web 服务。我们发现延迟偶尔会增加 10-30 毫秒，没有充分的理由。我们能够将有问题的代码段追踪到 LOH 和 GC。

我们将一些文本转换为其 UTF8 字节表示（实际上，我们使用的序列化库就是这样做的）。只要文本短于 85000 字节，延迟就稳定且短：平均约为 0.2 毫秒，达到 99%。一旦超过 85000 边界，平均延迟就会增加到约 1 毫秒，而 99% 会跳到 16-20 毫秒。Profiler 显示大部分时间都花在了 GC 上。可以肯定的是，如果我在迭代之间放置 GC.Collect，测得的延迟会回到 0.2 毫秒。

我有两个问题：

1. 延迟从何而来？据我了解，LOH 没有被压缩。SOH 正在被压缩，但没有显示延迟。
2. 有没有一种实用的方法来解决这个问题？请注意，我无法控制数据的大小并使其更小。

--