c# – IIS垃圾收集与许多appdomains挂起
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了c# – IIS垃圾收集与许多appdomains挂起,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含4622字,纯文字阅读大概需要7分钟。
内容图文
![c# – IIS垃圾收集与许多appdomains挂起](/upload/InfoBanner/zyjiaocheng/767/9e6813b5c9684c0baf71259052d724f8.jpg)
我们有一个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, Boolean, System.Runtime.Remoting.Messaging.IMethodCallMessage)+db
mscorlib_ni!System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(System.IO.Stream, System.Runtime.Remoting.Messaging.HeaderHandler, Boolean, Boolean, 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.SmuggledMethodCallMessage, 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, Boolean, 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挂起所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。