首页 > 解决方案 > 诊断在 IIS 上运行的网站中的零星锁定

问题描述

目标

确定在 IIS 上运行的 Web 应用程序偶尔锁定的原因。

问题

我们在 IIS 上运行的应用程序在一天中偶尔会锁定。当它锁定时,它将锁定所有工作人员和所有负载平衡实例。

环境与应用

该应用程序在 4 台不同的 Windows Server 2016 机器上运行。这些机器使用 ha-proxy 使用循环负载平衡方案进行负载平衡。该网站托管的 IIS 应用程序池配置为每个具有 4 个工作人员,并且它托管的应用程序是 32 位应用程序。IIS 实例未使用共享配置文件,但此应用程序的应用程序池都配置相同。

此应用程序是 IIS 应用程序池中的唯一应用程序。该应用程序是一个 ASP.NET Web API,使用的是 .NET 4.6.1。应用程序没有创建自己的线程。

理论

我对为什么会发生这种情况的理论是,我们收到的请求需要大约 5-30 分钟才能完成。每台机器都忙于为这些请求提供服务,因此它们看起来“被锁定”。该公司推出了自己的日志记录机制,据我所知,我们有大约需要 5-30 分钟才能完成的请求。负责该应用程序的团队已经清理了其中许多,但我仍然在日志中看到大约 5 分钟的请求。

我个人无法访问这些机器,因此我们的系统团队在发生这种情况时已经获得了应用程序的内存转储。在转储中,我通常会看到大约 50 个线程正在运行,并且它们都在我们的代码中。这些线程将遍布我们的应用程序,并且似乎不会在任何常见的代码段上停止。当应用程序正常运行时,转储将运行 3-4 个线程。我还查看了 ASP.NET\Requests Queued 之类的性能计数器,但它似乎从来没有任何请求排队。在这段时间内,CPU、内存、磁盘和网络的使用情况看起来很正常。使用windbg,除了终结器线程之外,没有一个线程似乎有很高的CPU时间,据我所知,它应该一直存在。

结论

我正在寻找一种方法来证明或反驳我关于我们为什么要锁定的理论以及我应该查看的任何指标或工具。

标签: iis

解决方案


因此,这个问题归结为我们的应用程序,它在一个包含 2,000,000 条记录的表上使用查询拼接到另一个表。内存会变得如此碎片化,以至于垃圾收集器花费更多的时间来寻找放置对象的位置并移动它们,而不是运行我们的代码。这就是为什么我们的应用程序似乎仍在工作以及为什么它们也不例外的原因。奇怪的是,IIS 会使请求超时,但会继续处理线程。


推荐阅读