我们怀疑在运行几个 ASP.NET Core API 和几个 .NET Core 控制台的服务器上遇到线程池饥饿的情况。
当我们怀疑线程池匮乏问题时，我在我们的一台服务器上运行了 perfview。然而，我在分析结果时遇到了一些麻烦。
I ran PerfView /threadTime collect约60秒。这是我得到的结果（我选择了一个来查看我们的 ASP.NET Core API 之一）：
看看“By Name”我们可以看到，有很多时间花在BLOCKED_TIME。如果双击，我将进入以下视图，我可以在其中展开其中一个节点以获得以下视图（覆盖的部分是我们的 API 进程的名称）：
这告诉我什么？我不应该能够看到到底是什么被阻止了吗？看起来问题是不是很多线程在一小段时间内阻塞了每个线程？
我们还能从中得出其他结论吗？
BLOCKED_TIME通常意味着线程根本没有执行任何操作的时期。这可能是 I/O 周期，其中涉及网络或其他类型的延迟，或者花费在等待锁上的时间（例如在使用信号量的情况下）。简而言之，这不一定能告诉您任何信息，因为线程空闲有完全标准且合理的原因。然而，大量的阻塞时间可能表明存在潜在的问题。也许您的网络延迟太多。也许您正在尝试在慢速驱动器上执行过多的文件系统工作。简而言之，它可能表明存在问题，也可能不表明问题，即使它确实表明存在问题，它也不能真正告诉您问题是什么。
一般来说，如果您遇到线程匮乏的情况，您首先应该考虑的是线程池利用率。您是否在任何可以使用异步的地方？您是否正在做一些网络应用程序中的大禁忌，例如使用Task.Run, Task.StartNew或者更糟的是，Thread.Start？所有这些创建的线程都来自同一个线程池，因此会成比例地减少服务器吞吐量。
有一种非常常见的模式，即尝试通过将长时间运行的作业转移到新线程来安排它们。这对网络应用来说就是死亡。池中的所有线程都是为了服务请求，而不是长时间运行的作业，因此，应该快速有效地处理请求，以便线程可以在短时间内返回到池中以处理其他请求。如果需要后台工作，则需要truly通过卸载到另一个进程甚至完全不同的机器来将其置于后台。
除此之外，也许您所获得的负载超出了服务器通常可以处理的负载。这总是有可能的。也许您需要垂直扩展系统资源（以及与之相关的线程池）。也许您需要通过复制此服务器并在前面添加负载均衡器来进行水平扩展。鉴于您在同一台服务器上运行多个不同的事物，水平扩展的一种简单方法是将这些事物简单地分配到它们自己的机器上。仅此一点就可能有很大帮助。然而，垂直或水平缩放应该是最后的选择。首先确保您有效地使用资源，然后再将更多资源投入到效率低下的事情上。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
