c# – IIS垃圾收集与许多appdomains挂起

概述我们有一个 Asp.net 4.5 mvc webapi,它有大约100个app域,每个域都包含一个扩展名. 现在我们不时挂起api.即使只返回字符串的状态api也没有响应,也没有一条路由响应. 当它挂起时,该站点有大约120个线程(这是很正常的)和大约12 GB RAM(这是不寻常的高). 当我们进行内存转储时,我们可以看到站点始终处于垃圾收集的中间. 大多数情况下,我们看到大多数线程都挂在堆栈 我们有一个 Asp.net 4.5 mvc webAPI,它有大约100个app域,每个域都包含一个扩展名.

现在我们不时挂起API.即使只返回字符串的状态API也没有响应,也没有一条路由响应.

当它挂起时,该站点有大约120个线程(这是很正常的)和大约12 GB RAM(这是不寻常的高).

当我们进行内存转储时,我们可以看到站点始终处于垃圾收集的中间.

大多数情况下,我们看到大多数线程都挂在堆栈中,代码处理应用程序域之间的序列化并等待GC.
我们还有很多序列化,比如app域通信和一些Redis缓存

等待大约5分钟的事件挂起并没有结束.是否存在与许多应用程序域相关的垃圾收集的已知问题？

由于站点在IIS中托管,因此后台GC应始终处于活动状态.

当我在GC性能计数器中查看时间时,我可以看到GC几乎一直在运行

我可以看到,当网站在gc中持续40％的时间

当站点处于此状态时,我也可以看到内存永久性地略微增加.

有关测试或尝试改进的任何提示？

将运行时升级到4.5.2时,它可能会有好处吗？
像这样：

ntdll!NtWaitForSingleObject+a KERNELBASE!WaitForSingleObjectEx+94 clr!CLREventWaitHelper2+38 clr!CLREventWaitHelper+1f clr!CLREventBase::WaitEx+70 clr!SVR::gc_heap::wait_for_gc_done+55 clr!SVR::WaitLonger+9e clr!SVR::GCHeap::Alloc+224 clr!JIT_New+142 [[HelperMethodFrame]] mscorlib_ni!System.Runtime.Serialization.ObjectManager.RegisterFixup(System.Runtime.Serialization.FixupHolder,Int64,Int64)+d1 mscorlib_ni!System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()+128 mscorlib_ni!System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(System.Runtime.Remoting.Messaging.headerHandler,System.Runtime.Serialization.Formatters.Binary.__BinaryParser,Boolean,System.Runtime.Remoting.Messaging.IMethodCallMessage)+db mscorlib_ni!System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(System.IO.Stream,System.Runtime.Remoting.Messaging.headerHandler,System.Runtime.Remoting.Messaging.IMethodCallMessage)+1bf mscorlib_ni!System.Runtime.Remoting.Channels.CrossAppDomainSerializer.DeserializeObject(System.IO.MemoryStream)+f8 mscorlib_ni!System.Runtime.Remoting.Messaging.SmuggledMethodCallMessage.FixupForNewAppDomain()+de8a4e mscorlib_ni!System.Runtime.Remoting.Channels.CrossAppDomainSink.Dodispatch(Byte[],System.Runtime.Remoting.Messaging.SmuggledMethodCallMessage,System.Runtime.Remoting.Messaging.SmuggledMethodReturnMessage ByRef)+33 mscorlib_ni!System.Runtime.Remoting.Channels.CrossAppDomainSink.DoTransitiondispatchCallback(System.Object[])+92 clr!CallDescrWorkerInternal+83 clr!CallDescrWorkerWithHandler+4a clr!dispatchCallDeBUGgerWrapper+1f clr!dispatchCallSimple+88 clr!ThreadNative::InternalCrossContextCallback+2ea [[ContextTransitionFrame]] [[HelperMethodFrame_PROTECTOBJ] (System.Threading.Thread.InternalCrossContextCallback)] System.Threading.Thread.InternalCrossContextCallback(System.Runtime.Remoting.Contexts.Context,IntPtr,Int32,System.Threading.InternalCrossContextDelegate,System.Object[]) mscorlib_ni!System.Runtime.Remoting.Channels.CrossAppDomainSink.DoTransitiondispatch(Byte[],System.Runtime.Remoting.Messaging.SmuggledMethodReturnMessage ByRef)+a0 mscorlib_ni!System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage(System.Runtime.Remoting.Messaging.IMessage)+15d mscorlib_ni!System.Runtime.Remoting.ProxIEs.RemotingProxy.CallProcessMessage(System.Runtime.Remoting.Messaging.IMessageSink,System.Runtime.Remoting.Messaging.IMessage,System.Runtime.Remoting.Contexts.ArrayWithSize,System.Threading.Thread,System.Runtime.Remoting.Contexts.Context,Boolean)+8c mscorlib_ni!System.Runtime.Remoting.ProxIEs.RemotingProxy.Internalinvoke(System.Runtime.Remoting.Messaging.IMethodCallMessage,Int32)+22c mscorlib_ni!System.Runtime.Remoting.ProxIEs.RealProxy.PrivateInvoke(System.Runtime.Remoting.ProxIEs.MessageData ByRef,Int32)+1f4 clr!CTPMethodtable__CallTargetHelper3+12 clr!CallTargetWorker2+74 clr!CTPMethodtable::OnCall+1fb clr!transparentProxyStub_CrossContextPatchLabel+a [[TPMethodFrame] (SR.BusPortal.ProvIDers.Contract.Common.IAdapterSearcher.SearchAsync)] SR.BusPortal.ProvIDers.Contract.Common.IAdapterSearcher.SearchAsync(SR.BusPortal.ProvIDers.Contract.Common.AdapterSearchParameters) SR.BusPortal.Search.Steps.SearchStepOneWay`2+<SearchOneWayAsync>d__3[[System.__Canon,mscorlib],[System.__Canon,mscorlib]].MoveNext()+73

解决方法 经过一些进一步调查后,appdomains不是原因.
我希望这能为其他人节省很多搜索:-)

我们在webAPI进程中有一个很大的Memory GraphDatabase(它使用了大约30GB的RAM).因此,我们的webAPI项目和同一过程中的图形数据库存在问题,GC从未成功结束该过程.使用非异步gc,问题更好,但有时候有点滞后.

将此数据库分离到自己的服务后,此行为永远不会再次发生.

还有很多关于如何优化GC代码的帖子可能有所帮助

总结

以上是内存溢出为你收集整理的c# – IIS垃圾收集与许多appdomains挂起全部内容，希望文章能够帮你解决c# – IIS垃圾收集与许多appdomains挂起所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。