了解 PerfView 中的 BLOCKED_TIME

Question

我们怀疑在运行几个 ASP.NET Core API 和几个 .NET Core 控制台的服务器上遇到线程池饥饿。

我在我们的一台服务器上运行了 perfview，因为我们怀疑线程池饥饿有问题。但是，我在分析结果时遇到了一些麻烦。

我跑PerfView /threadTime collect了大约60秒。这是我得到的结果（我选择了一个来查看我们的 ASP.NET Core API 之一）：

查看“按名称”，我们可以看到在BLOCKED_TIME. 如果我双击，则会进入以下视图，我可以在其中展开节点之一以获取以下视图（被覆盖的部分是我们的 API 进程的名称）：

这告诉我什么？我不应该能够看到究竟是什么阻塞？看起来问题是很多线程在短时间内阻塞了每个线程吗？

我们还能从中得出什么其他结论吗？

Answer 1

BLOCKED_TIME通常意味着线程根本不做任何事情的时期。这可能是 I/O 期间，其中涉及网络或其他类型的延迟，或者在等待锁定（例如在有信号量的情况下）所花费的时间。简而言之，这不一定会告诉您任何事情，因为线程空闲是完全标准且合理的。但是，阻塞所花费的大量时间可能表明存在潜在问题。也许你有太多的网络延迟。也许您正试图在慢速驱动器上执行过多的文件系统工作。简而言之，它可能表示也可能不表示有问题，即使确实表示有问题，也不能真正告诉您问题是什么。

一般来说，如果您遇到线程饥饿，您应该首先考虑的是线程池利用率。你在任何地方都在使用异步吗？您是否正在做 Web 应用程序中的大禁忌，例如使用Task.Run，Task.StartNew或更糟的是，Thread.Start？所有这些创建的线程都来自同一个线程池，因此会按比例降低服务器吞吐量。

尝试通过将它们改组到新线程来安排长时间运行的作业是一种非常常见的模式。这是 Web 应用程序的死亡。池中的所有线程都用于服务请求，而不是长时间运行的作业，因此，应快速有效地处理请求，以便线程可以在短时间内返回到池中以处理其他请求。如果您需要后台工作，您需要真正后台工作，通过卸载到另一个进程甚至完全不同的机器。

总而言之，也许您只是获得了比服务器通常可以处理的更多的负载。那总是有可能的。也许您需要垂直扩展您的系统资源（以及带有它的线程池）。也许您需要通过在前面使用负载平衡器复制此服务器来进行水平扩展。鉴于您在同一台服务器上运行多个不同的东西，横向扩展的一种简单方法是将这些东西简单地分配到他们自己的机器上。仅此一项就可能有很大帮助。但是，垂直或水平缩放应该是最后的手段。在将更多资源投入低效事物之前，请确保您首先有效地使用资源。