.net System.Runtime.InteropServices.COMException（0x80070008）：没有足够的存储空间来处理此命令

我正在尝试诊断此异常：

System.Runtime.InteropServices.COMException (0x80070008): Not enough storage is available to process this command. (Exception from HRESULT: 0x80070008)
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(RuntimeType objectType)
at System.Runtime.Remoting.RemotingServices.AllocateUninitializedObject(Type objectType)
at System.Runtime.Remoting.Activation.ActivationServices.CreateInstance(Type serverType)
at System.Runtime.Remoting.Activation.ActivationServices.IsCurrentContextOK(Type serverType, Object[] props, Boolean bNewObj)
at Oracle.DataAccess.Client.CThreadPool..ctor()
at Oracle.DataAccess.Client.OracleCommand.set_CommandTimeout(Int32 value)
...

看起来，任何正常类型的“存储”都没有达到任何极限。该应用程序使用了大约400MB的内存、70个线程、2000个句柄，硬盘有很多GB的空闲空间。这台计算机运行的是32位Windows 2003 Enterprise Server，内存为16GB，因此内存不应成为问题

应用程序作为windows服务运行，因此没有使用GDI对象。GDI句柄不足是导致此异常的常见原因

数据库连接、命令和读卡器都用using块包装，因此应该正确地清理它们

更新：将我们使用的线程数从12个减少到4个似乎解决了这个问题。在我们持续4到8个小时之前，我们成功地运行了24个多小时，没有任何错误。

---

更新2:我从来没有弄清楚我们用完了什么资源，但减少线程数量似乎解决了这个问题。或者至少隐藏了它。

看起来有什么东西在循环和实例化堆上的太多对象，所以堆上的内存不足。在调用代码中查找任何循环。

另一个需要考虑的因素是内存碎片。 您可以执行的最大单次分配等于进程可用的最大连续内存块。由于碎片，这几乎总是小于进程中可用的内存总量。也就是说，分配的内存块位于2个空闲内存块“碎片”空间之间

进程中的碎片越多，可用的最大连续内存块就越小。我见过这样的情况，即有接近1GB的内存可用，但最大的连续块大约是10MB

---

您是否检查了此进程中的内存碎片？

您确实为您的进程消除了此错误的所有明显来源。这可能实际上是操作系统问题。在服务器上总是处于压力之下的一个资源是内核内存池。很容易看到，TaskMgr.exe会将其显示在“性能”选项卡上

它在某种程度上与您的调用堆栈相匹配，看起来Oracle提供程序正在为线程池创建线程。线程在进程中占用1兆字节，在内核内存池中占用24 KB，当线程切换到内核模式时用作堆栈

---

背景信息是。

其实算了吧，谷歌搜索让它看起来像是32位机器上的Oracle内存问题，所以我怀疑我现在能帮上忙。暗中拍摄（见interop）您正在呼叫Marshal.ReleaseComObject吗？@Marvin:互操作由Oracle.32位进程在32位Windows上完成。那么为什么您有16GB的RAM？16GB的物理RAM可由32位Windows Server 2003通过PAE访问。PAE不会影响应用程序可以访问的虚拟内存量。请参阅/3GB开关和“大地址感知”关键字，将虚拟内存增加到3GB。关于如何检测内存碎片有何建议？我目前正在对测试服务器上运行的进程尝试DebugDiag的内存泄漏检测。碎片似乎不是问题，应用程序出现问题时，最大的可用块为500MB。这是使用sysinternals vmMap工具收集的。这似乎不是问题，因为有超过40MB的可用非页面池和100MB的页面池。我还查看了所有“对象”事件信号量等的perfmon计数器，我们似乎也没有泄漏它们。好了，是时候给Oracle打个电话了。