首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >理解BLOCKED_TIME在PerfView中的应用

理解BLOCKED_TIME在PerfView中的应用
EN

Stack Overflow用户
提问于 2019-03-08 15:37:25
回答 1查看 2.8K关注 0票数 5

我们怀疑在运行几个ASP.NET核心API和几个.NET核心控制台的服务器上存在线程池饥饿现象。

我运行了一个我们的服务器,因为我们怀疑线程池饥饿的问题。然而,我在分析结果时遇到了一些困难。

我运行了大约60秒的PerfView /threadTime collect。这就是我得到的结果(我选择一个来查看我们的ASP.NET核心API之一):

看看“点名”,我们可以看到,在BLOCKED_TIME上花费了大量的时间。如果双击,就会看到以下视图,在该视图中,我可以展开一个节点以获得以下视图(覆盖部分是我们API进程的名称):

那能告诉我什么?我难道看不出到底是什么挡住了吗?看起来问题是很多线程阻塞每个线程的时间很短吗?

我们还能从中得出其他结论吗?

EN

回答 1

Stack Overflow用户

回答已采纳

发布于 2019-03-08 16:05:09

BLOCKED_TIME通常是指线程根本不执行任何操作的句点。这可能是I/O期间,其中涉及网络或其他类型的延迟,或花费在锁上的等待时间,例如在有信号量的情况下。简而言之,这并不一定能告诉您任何事情,因为线程被闲置有完全标准和合理的理由。然而,一段相当长的时间被阻塞可能是一个潜在的问题的迹象。也许你有太多的网络延迟。也许你试图在一个缓慢的驱动器上做太多的文件系统工作。简而言之,它可能表示一个问题,也可能没有指出一个问题,即使它确实表明了一个问题,它也没有真正告诉您问题是什么。

通常,如果您正在经历线程饥饿,首先要注意的是线程池的利用率。您是否在所有可能的地方使用异步?你在做的事情在网络应用中是不可忽视的,比如使用Task.RunTask.StartNew,或者更糟的是,Thread.Start?所有创建的线程都来自同一个线程池,因此相应地降低了服务器吞吐量。

有一种非常常见的模式,试图通过将长时间运行的作业调整到新线程来调度它们。这对一个网络应用来说是一种死亡。池中的所有线程都是为请求服务的,而不是长时间运行的作业,因此,应该快速有效地处理请求,以便将线程返回到池中,以便在短时间内发送其他请求。如果您需要后台工作,您需要真正的背景,通过卸载到另一个进程,甚至一个完全不同的机器。

除此之外,您可能只是得到的负载超过了服务器通常所能处理的负荷。这总是有可能的。也许您需要垂直缩放您的系统资源(以及它的线程池)。也许您需要通过在前面使用负载均衡器复制此服务器来进行水平缩放。考虑到在同一台服务器上运行多个不同的东西,水平扩展的一个简单方法就是将这些东西分配给他们自己的机器。光是这一点可能会有很大帮助。然而,缩放,无论是垂直的还是水平的,都应该是你最后的选择。首先要确保资源的使用效率,然后再将更多的资源投入到效率低下的事情上。

票数 10
EN
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://stackoverflow.com/questions/55066460

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档