【问题标题】:How to avoid ThreadPool bottleneck when it runs out of threads线程耗尽时如何避免 ThreadPool 瓶颈
【发布时间】:2015-03-27 08:20:18
【问题描述】:

我们有一个应用程序有一些时间限制,假设我们需要每 500 毫秒执行一次操作,它是一种看门狗,所以如果我们在 500 毫秒之前不发送消息,就会发生坏事。

应用程序大量使用 ThreadPool,而这个看门狗事物与 ThreadPool 交互。

我们发现在一些低端机器上,有时当我们排队一个新的工作项时,执行它需要大约 800 毫秒,因此看门狗会触发。我们猜测这与 ThreadPool 线程耗尽/创建新线程有关。

有没有办法避免这种情况,例如强制 ThreadPool 提前或在不同的线程中创建线程,这样看门狗就不必等到 ThreadPool 可以执行请求?

【问题讨论】:

  • 是的,有办法。但是,为什么您发现自己首先用完了 ThreadPool 线程?也许值得看看在哪里可以使用异步 I/O 而不是阻塞 I/O?
  • 这个“看门狗”是否在其专用线程上运行?
  • @Magnus:它在专用线程上运行,而不是来自线程池,但它一直等到收到来自线程池线程的消息。
  • 线程池只用于这个任务吗?这是一些计划任务,应该每 500 毫秒触发一次,并且可能有更多并发的任务实例?
  • @user3360241:不,theadpool 用在好几个地方。

标签: c# .net multithreading threadpool timing


【解决方案1】:

lawliet29 的回复在一定程度上有所帮助。 但是即使有很多线程,线程池也会变得饱和,并且一些任务可能会在全局任务队列的末尾排队。

我们在 Akka.NET 中遇到了同样的问题,我们的系统参与者即使在高负载下也必须执行。

我们现在将这些敏感任务移到它自己的专用线程池中,这样这些任务就不会在全局池队列的末尾结束。

https://github.com/helios-io/DedicatedThreadPool

我们可以使用特殊的任务调度器将任务调度到这个队列中。

【讨论】:

  • 似乎是一个不错的选择,但由于当前的 ThreadPool 是一个静态变量,因此需要付出中等的努力才能将其包含在我们的代码中。还是谢谢。
【解决方案2】:

您可以尝试使用ThreadPool.SetMinThreads 方法。

【讨论】:

  • 我该怎么办?在这里放一个大数字,在 SetMaxThreads 中放一个更大的数字?这样就行了?
猜你喜欢
  • 2019-02-21
  • 2010-12-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-05-23
  • 1970-01-01
  • 2013-02-03
相关资源
最近更新 更多