Unity未处理导致服务器死机？
我们有一个由大约 40 台服务器组成的服务器场，我们每隔几周就会向其滚动代码。当我们实时滚动代码时，我们注意到的一件事是，在部署程序集并执行 IIS 重置并将其放回 BigIp (F5) 后，它接收到的流量将被服务器锁定大约 10 分钟，客户端将一直旋转，直到最终暂停。
观察性能监视器，我们可以看到finally 的数量和固定对象的数量急剧增加，这促使我调查内存问题。
因此，我开始研究 Unity IoC 配置。在 global.asax.cs 中，我们注册了大约 15 个接口，其中大多数接口使用 ContainerControlledLifetimeManager 来管理生命周期。通常，除了这十分钟的窗口之外，代码永远不会出现问题，因此我的第一个想法是内存或资源管理问题。
有谁知道您是否必须显式处理 Unity 容器的 Dispose() 或者这是由 Unity 以某种方式自动处理的？我今天注意到没有为 Application_End 进行 Dispose 接线，所以我的想法是，当服务器在 IIS 重置后重新启动时，可能会出现 Unity 或对象资源问题，直到 GC 恢复并释放内存（十分钟）需要出现）。
任何帮助表示赞赏！
We have a server farm of about 40 servers that we roll code to every couple weeks. One thing we noticed when we roll the code live is after deploying the assemblies and performing an IIS reset and put it back in the BigIp (F5) and it receives traffic the server will lockup for about 10 minutes and clients will just spin until an eventual timeout.
Looking at the perfmon we can see a dramatic spike in number of finally's and number of pinned objects btw which lead me to investigate memory issues.
So one thing I started looking into it our Unity IoC configuration. In the global.asax.cs we are registering about 15 interfaces where most are using the ContainerControlledLifetimeManager to manage the lifetime. Normally there is never a problem with the code except in this ten minute window so my first thought was a memory or resource management issue.
Does anyone know if you have to explicitly Dispose() of your Unity Container or is this handled by Unity automagically somehow? I noticed today that there was no Dispose wiring in place for Application_End so my thought was maybe when the servers are brought back on after the IIS reset there is a Unity or object resource issue until the GC comes around and frees the memory (the ten minutes it takes to come up).
Any help is appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
执行 iisreset 将终止当前正在运行的 w3wp.exe 进程，因此未正确处理
Application_End中的 unity 对象不太可能导致启动时出现性能问题。旧的 Web 进程可能无法正确释放新 Web 进程所依赖的文件系统或其他资源，但我认为如果是这种情况，您会看到文件访问或其他一些错误。由于您正在执行 iisreset，因此我会仔细查看应用程序首次启动时运行的代码。也许有一些组件需要花费大量时间来启动（即，假设有一个单例类型类从数据库下载并缓存一堆内容），这可能会导致速度变慢，可能只有在与以下压力相结合时处理所有等待的 HTTP 请求。另外，请记住，ASP.NET 在编译首次使用的应用程序时会产生大量开销。由于您的 Web 应用程序似乎位于负载均衡器后面，因此您可能需要想出一种方法来“启动”每个单独的 Web 服务器上的应用程序，然后再将该 Web 服务器添加回负载均衡器，这可以通过以下方式完成只需在该 Web 服务器上本地加载页面即可。启动应用程序将允许 Web 应用程序自行初始化，而无需处理任何外部请求，这应该会缩短启动时间。
长话短说，在关注关闭问题之前，我会调查启动问题并看看可以调整哪些内容。
Performing an iisreset will kill the currently running w3wp.exe process, so it's unlikely that not properly disposing of unity objects in
Application_Endwould cause performance issues on startup. It is possible that the old web process doesn't properly release file system or other resources the new web process depends upon, but I think you'd see file access or some other errors if that were the case.Since you're performing an iisreset, I would look closely at the code that runs when the application starts for the first time. Maybe there are some components that take alot of time to start up (i.e., say there is a singleton type class that downloads and caches a bunch of stuff from the database) that are causing the slow down, possibly only when combined with the stress of handling all of the waiting HTTP requests. Also, keep in mind that ASP.NET will incur a bunch of overhead as it compiles the application to be used the first time. Since it seems that your web application is behind a load balancer, you may want to come up with a way to "prime" the application on each individual web server before you add that web server back to the load balancer, which could be accomplished by just loading a page locally on that web server. Priming the application would allow the web app initialize itself without having to handle any outside requests, which should improve the startup time.
Long story short, I would investigate startup issues and see what I could tune there before I focused on shutdown issues.