【问题标题】:Optimal number of items to keep queued for the thread pool in .NET?在 .NET 中为线程池排队的最佳项目数?
【发布时间】:2009-12-03 14:10:04
【问题描述】:

我正在构建一个后台处理引擎,它支持丢弃待处理和正在处理的项目。这适用于需要对某些输入元素进行大量处理的 winforms 应用程序,因此我正在构建一个队列引擎,我可以在其中将工作负载项排入队列,当它们被处理时,我会收到结果通知。

问题是,这个队列开始时几乎总是包含很多项目,我认为与其将所有内容都转储到线程池,不如只将前 N 个项目放入线程池,并继续回填当它们被处理时。我想这样做的原因是,一旦我将它们转储到线程池中,它们被处理,即使它们被标记为丢弃,它们仍然会占用排队时间。

通过我所做的回填实现,如果项目被丢弃,我可以从队列中删除它们,并且只有在轮到它们时才将它们放入队列中,可以这么说。

所以问题是,我将如何计算这个数字 N,即要放入并保留在线程池队列中的项目数。

我考虑过的问题:

  • 我可能想要将 2 * 个处理器(我认为这是典型的项目数)加入队列,以确保所有处理器都在工作
  • 但是,如果某些项目的实际处理速度非常快(可能会发生),那么线程池中的队列在我自己的类可以回填更多工作之前就已经耗尽,所以也许我想要一个更大的数字避免未充分利用处理器
  • 我是否应该创建一些自动调整例程来根据每个项目的当前时间计算最佳数字,这样如果它们都超快,数字会高得多,如果处理需要一点时间,它应该保持在低位吗?

你怎么看?

:好的,由于其中一个答案,我会再解释一下。放入队列的每个项目都由独特的东西作为键。如果我使用与现有项目相同的键将另一个项目转储到队列中,则该旧项目被视为“丢弃”,应该被删除。如果正在处理项目,则工作负载项目上的属性设置为 true,即“IsDicarded”属性,处理方法负责调用该属性。如果它检测到丢弃的项目,它应该提前退出,不返回任何结果。

也许我应该多做一些试验,然后尝试将所有内容都转储到线程池中。

新问题:我可以排队的物品数量有限制吗?如果没有,那么这会很容易地简化我的课程。

注意:当我说“冗长的处理”时,我的意思是大约 1-10 秒。线程池甚至是最好的吗?我在网上看到关于“处理应该快速”的注释,但从未提及“快速”是什么。这里是毫秒级的快吗?

【问题讨论】:

    标签: .net threadpool workload


    【解决方案1】:

    你知道阿米吧的Smart Thread Pool吗?

    似乎它的实现允许您取消未处理的项目并根据需要动态增加线程,直到达到硬限制;我个人使用100 * Environment.ProcessorsCount

    【讨论】:

    • 不,我不知道那个,我会调查一下,它看起来很有希望。最好的代码是我不必编写的代码,开箱即用 :)
    【解决方案2】:

    您是否可以通过修改您的项目以在执行任何工作之前首先检查它们是否仍然需要来简化方法?这将解决限制池中数量的问题,因为您可以简单地将它们全部添加,当每个项目被处理时,如果不再需要它就会退出。

    可以进行的操作数 排队到线程池是有限的 仅通过可用内存;但是,那 线程池限制数量 可以在 同时处理。默认, 限制为每个 250 个工作线程 CPU 和 1,000 个 I/O 完成线程。

    您可以控制最大数量 线程使用 GetMaxThreads 和 SetMaxThreads 方法。

    http://msdn.microsoft.com/en-us/library/0ka9477y.aspx

    【讨论】:

    • 是的,他们这样做了,发送到委托的项目包含他们需要调用的“IsDicarded”方法,不仅在之前,而且在处理过程中,如果处理时间很长,提前中止.可能是我把事情复杂化了,应该只跟踪现有的项目,它们是键控的,这样我就可以找到它们,如果更换它们就丢弃它们,然后将它们全部转储到线程池中。也许我应该尝试那个解决方案。
    • 听起来确实值得一试,尤其是如果这意味着要避免手动调整池大小和管理池的其他复杂性。
    • 你知道我可以放入线程池的工作项的数量是否有限制吗?
    • 现在是做一些实验的好时机 :)
    • 啊,看来我需要看看鲁本斯提到的智能线程池,我需要优先级支持。例如,当打开相关表单时,所有数据都排队等待处理,但如果用户更改了网格中的某些特定列,则这些列的结果会以更高的优先级重新排队处理,这样最终所有数据都被处理,但无论用户摆弄什么都会首先被处理。
    猜你喜欢
    • 2016-07-24
    • 1970-01-01
    • 2015-03-22
    • 2011-08-21
    • 1970-01-01
    • 2011-10-08
    • 1970-01-01
    • 2013-07-09
    • 1970-01-01
    相关资源
    最近更新 更多