分析一个 WCF 客户端应用程序(我没有编写,而且仍然不太了解),该应用程序通过 SOAP 与一堆服务进行通信,运行几天后会抛出 OutOfMemoryException,我发现 .net 的 PooledBufferManager 会即使应用程序内存不足,也永远不要释放未使用的缓冲区,从而导致 OOME。
这当然符合规范:http://msdn.microsoft.com/en-us/library/ms405814.aspx http://msdn.microsoft.com/en-us/library/ms405814.aspx
当缓冲池被破坏时,池及其缓冲区将被破坏
通过垃圾收集来回收。
请随意回答下面的一个问题,因为我有很多问题,其中一些是更一般性的,还有一些是针对我们的应用程序对 BufferManager 的使用的。
首先是关于(默认 Pooled)BufferManager 的几个常见问题:
1)在有 GC 的环境中,为什么我们需要一个 BufferManager 来保留未使用的内存,即使这会导致 OOME?我知道,有 BufferManager.Clear(),你可以用它来manually摆脱所有缓冲区 - 如果您有权访问 BufferManager,也就是说。请参阅下文以了解为什么我似乎无权访问。
2)尽管 MS 声称“这个过程比每次需要使用缓冲区时创建和销毁缓冲区要快得多”,但他们不应该将其留给 GC(例如其 LOH)并优化 GC ?
3)当执行 BufferManager.Take(33 * 1024 * 1024) 时,我将获得 64M 的缓冲区,因为 PooledBufferManager 将缓存该缓冲区以供以后重用,这可能 - 好吧,在我的情况下它不是,因此它纯粹是浪费内存 - 比如说,需要 34M、50M 或 64M。那么创建一个像这样可能非常浪费的 BufferManager 是否明智,它由 HttpsChannelFactory 使用(我认为默认情况下)?我不明白内存分配的性能有多么重要,特别是当我们谈论 WCF 和网络服务时,应用程序将每 10 秒 TOPS 进行一次对话,通常需要更多秒甚至几分钟。
现在有一些与我们的应用程序使用 BufferManager 相关的更具体的问题。该应用程序连接到几个不同的 WCF 服务。对于每个连接,我们都维护一个用于 http 连接的连接池,因为连接可能同时发生。
检查一个堆转储中的单个最大对象,这是一个 64M 字节数组,仅在初始化时在我们的应用程序中使用过一次,之后就不需要了,因为服务的响应仅在初始化时那么大,顺便说一句。对于我使用过的许多应用程序来说这是典型的,即使这可能需要优化(缓存到磁盘等)。 WinDbg 中的 GC 根分析产生以下结果(我将专有类的名称清理为“MyServiceX”等):
0:000:x86> !gcroot -nostacks 193e1000
DOMAIN(00B8CCD0):HANDLE(Pinned):4d1330:Root:0e5b9c50(System.Object[])->
035064f0(MyServiceManager)->
0382191c(MyHttpConnectionPool`1[[MyServiceX, MyLib]])->
03821988(System.Collections.Generic.Queue`1[[MyServiceX, MyLib]])->
038219a8(System.Object[])->
039c05b4(System.Runtime.Remoting.Proxies.__TransparentProxy)->
039c0578(System.ServiceModel.Channels.ServiceChannelProxy)->
039c0494(System.ServiceModel.Channels.ServiceChannel)->
039bee30(System.ServiceModel.Channels.ServiceChannelFactory+ServiceChannelFactoryOverRequest)->
039beea4(System.ServiceModel.Channels.HttpsChannelFactory)->
039bf2c0(System.ServiceModel.Channels.BufferManager+PooledBufferManager)->
039c02f4(System.Object[])->
039bff24(System.ServiceModel.Channels.BufferManager+PooledBufferManager+BufferPool)->
039bff44(System.ServiceModel.SynchronizedPool`1[[System.Byte[], mscorlib]])->
039bffa0(System.ServiceModel.SynchronizedPool`1+GlobalPool[[System.Byte[], mscorlib]])->
039bffb0(System.Collections.Generic.Stack`1[[System.Byte[], mscorlib]])->
12bda2bc(System.Byte[][])->
193e1000(System.Byte[])
查看 BufferManager 管理的其他字节数组的 gc 根发现其他服务(不是“MyServiceX”)具有不同的 BufferPool 实例,因此每个服务都在浪费自己的内存,他们甚至没有共享浪费。
4)我们在这里做错了什么吗?我无论如何都不是 WCF 专家,那么我们可以让各种 HttpsChannelFactory 实例都使用相同的 BufferManager 吗?
5)或者甚至更好,我们是否可以告诉所有 HttpsChannelFactory 实例根本不使用 BufferManager,并要求 GC 完成其该死的工作,即“管理内存”?
6)如果问题 4) 和 5) 无法得到解答,我是否可以访问所有 HttpsChannelFactory 实例的 BufferManager 并手动调用它们上的 .Clear() - 这远非最佳解决方案,但它已经有帮助了,在我的这样一来,在一个服务实例中不仅可以释放上述64M,还可以释放64M + 32M + 16M + 8M + 4M + 2M!因此,仅此一项就可以使我的应用程序运行更长时间,而不会遇到内存问题(不,除了 BufferManager 之外,我们没有内存泄漏问题,尽管我们确实消耗了大量内存并在过程中积累了大量数据很多天,但这不是这里的问题)