诊断在IIS上运行的网站中的零星锁定

Question

目标

确定在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时间，据我所知，终结器线程应始终存在。

结论

我正在寻找一种方法来证明或反驳为什么我们要锁定的理论以及我应该研究的任何度量标准或工具。

Answer 1

因此，这个问题归结为我们的应用程序在一个表中使用了针脚查询，该表中有2,000,000条记录到另一个表。内存变得如此分散，以至于垃圾回收器比运行我们的代码花费更多的时间来寻找放置对象并将它们移动的地方。这就是为什么我们的应用程序仍在工作，并且它们也不例外的原因。奇怪的是IIS会使请求超时，但会继续处理线程。