【问题标题】:Setting a low thread priority for a heavy load task为重负载任务设置低线程优先级
【发布时间】:2012-08-30 08:33:33
【问题描述】:

首先,感谢所有回复!

我想更具体一些 - 我有一个网站,其中显示了一些当前和历史报告。我希望能够允许用户删除全部或部分历史记录,同时仍在浏览网站。

因此,我想运行一个单独的线程来处理删除数据,但我想给这个线程一个低优先级,这样它就不会使网站变慢或无响应。

我现在正处于设计阶段,希望能提供一些策略建议。谢谢!

【问题讨论】:

  • 对你的记忆毫无帮助,而且它确实有一些严重的缺点,尽管不适用于其他一切。应用程序的其余部分在做什么,这可能是一个完全独立的应用程序吗?您有多少个内核,这是保持 100% 的总 CPU 还是仅占其中一个 CPU 的 100%?
  • 您在使用数据库吗?如果没有,听起来你应该朝那个方向前进。

标签: c# .net multithreading cpu-usage thread-priority


【解决方案1】:

你应该没事的。降低 CPU 密集型后台任务的优先级以允许来自 GUI 和/或其他应用程序的“正常”响应是更改线程优先级的更好用途之一。

请注意,降低线程优先级不会对除 CPU 之外的任何资源产生巨大影响,但仍然值得使用 IME。

如果您想在运行应用程序时继续使用 Firefox、Office、VLC 等,那么,可以,降低 CPU 密集型线程的优先级。然后,您应该可以在等待结果出来的同时浏览 SO、听一些专辑或看几部电影 :)

【讨论】:

    【解决方案2】:

    请注意,如果您想更改线程的优先级,您应该确保它是您自己创建的。更改线程池线程的优先级并不好。这意味着避免使用新的任务功能,除非您准备编写不使用线程池的TaskScheduler

    如果适合您的方案,还可以考虑设置进程优先级。请参阅MSDN 了解更多信息。这将同样影响线程。

    编辑:感谢您提供更多信息。听起来好像您的代码托管在 IIS 中。从this answer 我们可以确认IIS 使用与ThreadPool.QueueUserWorkItem 相同的线程池——标准的.NET 线程池。因此你不能改变线程池线程的优先级;这些线程属于 IIS。

    可以创建自己的线程。但似乎不建议尝试像这样在 IIS 中托管后台操作。例如,您永远不知道应用程序池何时会被回收。

    • 最好考虑几个其他选项。可能长时间运行的后台操作的最佳解决方案似乎是workflow services。与 AppFabric Server 结合使用时,这些功能非常强大,听起来就像可以处理您的情况一样。
    • 更简单的替代方法是将进程移到 IIS 之外。也许用户的操作可以将项目标记为删除,然后可以运行 IIS 之外的计划任务来执行缓慢的操作。

    【讨论】:

    • 为什么这不是一个好主意?如果你是唯一一个使用游泳池的人,为什么不呢?也就是说,我不知道如何有效地做这样的事情——优先级真的只需要设置一次,那么你在哪里做呢?
    • 嗯,你说得有道理。在您的长时间运行的代码之前,您可以输入Thread.CurrentThread.Priority = ThreadPriority.BelowNormal。这不是一个好习惯,尽管在您的情况下可能没问题。同一进程中的任何其他代码(可能稍后添加)都不会期望线程池线程具有非标准优先级。我想说一个更好的选择是设置会影响所有线程的进程优先级 (System.Diagnostics.Process.GetCurrentProcess().PriorityClass=System.Diagnostics.ProcessPriorityClass.BelowNormal)。
    【解决方案3】:

    我会使用 ThreadPool.UnsafeQueueUserWorkItem(new WaitCallback(MyDeleteMethod), itemsTobeDeleted)

    MyDeleteMethod 中,您可以考虑在不同的批量中中断删除过程。换句话说,您可以指定每次运行 delete 方法时要删除的最大行数。

    如果您担心数据库池中的可用连接数,您可以通过定义一个静态对象(带有计时器)并将 itemsTobeDeleted 添加到该列表中来提高性能(您需要使用锁进行同步访问)。每当计时器 Elapsed 事件触发时,您都可以执行批量删除(例如,您有 5,000 条记录,您将删除它们 500 x 500)。

    【讨论】:

    • 为什么使用 UnsafeQueueUserWorkItem 方法而不是简单的 QueueUserWorkItem?
    • 好问题,区别在于安全权限的验证。不安全版本不关心调用代码的权限,并在自己的权限范围内运行所有内容,这会稍微提高性能。
    猜你喜欢
    • 2014-10-27
    • 2012-02-01
    • 1970-01-01
    • 1970-01-01
    • 2014-11-26
    • 2015-02-17
    • 1970-01-01
    • 1970-01-01
    • 2011-04-19
    相关资源
    最近更新 更多