.net 内存充足时，跨不同应用程序池出现多个OutOfMemoryException

我正试图找出导致OutOfMemoryException的原因

以下是有关我们设置的事实：

• 我们在同一台Windows 2019服务器上运行大约70个.NET Framework 4.8 web应用程序，每个应用程序都位于各自的应用程序池中
• 应用程序以64位模式运行（在任务管理器中验证）
• 在这一天中，我们看到大量OutOfMemoryException在不同的应用程序中同时发生
• OutOfMemoryException出现在代码的不同部分
• 总体内存使用率约为机器容量的85%，这是一台大型机器，即可用内存约为30-40G。这台机器在一天中的使用量通常都在这个水平上（我想这是意料之中的）
• 遇到错误的应用程序正在使用3到6GB的RAM
• 分页文件设置为自动管理
• 未设置应用程序池的专用内存和虚拟内存限制（根据IIS中的设置，它们设置为0）
• 我们进行了内存转储并分析了DotMemory中的使用情况，但没有看到任何特别意外的情况

据我所知，可能发生内存不足错误的原因有几个，但在这种情况下，这些原因对我来说都没有意义

我们似乎并没有真正耗尽机器上的内存，因为我们有很多内存和足够的页面文件空间

这些都是现代的64位应用程序，而大多数旧的内存限制问题（例如无法分配大于2G字节的对象）不再适用

如果问题是由于碎片导致无法分配足够的连续空间，那么我们希望首先看到与较大对象相关的错误。但是我们看到的行为是相对较小的对象（例如，最多10到100 MB）的异常集群

---

问题可能是什么？我们还可以采取哪些其他步骤来诊断问题？

问题是应用程序实际运行的是32位模式，因此内存有限

有趣的是，TaskManager欺骗了我们，说这个进程是在64位模式下运行的。但是使用检查DLL显示它实际上是以32位运行的

---

应用程序被设置为使用“任意CPU”运行，并在64位机器上编译和运行。但我们认为它恢复到32位是因为引用了一个名为。正如在该包的项目站点上所解释的，指定x64明确地解决了这个问题。

大于~80K的对象被分配到大对象堆（LOH）中，并且在GC期间不会对该堆进行碎片整理。如果一个应用程序运行大量短生命的大对象，LOH可能会被分割得太多，以至于没有足够的连续空间来分配对象。如果使用dotMemory，则会有一个关于所需视图的帮助主题。谢谢Ed.ward，这个解释确实有道理，但我认为这不是我们的问题所在。