【问题标题】:Why would this thread in my program be starving?为什么我的程序中的这个线程会饿死?
【发布时间】:2016-10-19 03:30:14
【问题描述】:

我有一个大约有 80 个线程的程序。它在 linux 3.36 上运行在 ~50ish 核心机器上。最多有 2 个这样的程序同时运行,并且它们是相同的。机器上没有其他任何东西在运行。

线程本身是具有 SCHED_RR(循环)策略的实时 linux pthread。

  • 10 是最高优先级(是的,我将 ulimit 设置为 99),并将 cpu 亲和性设置为 10 个核心。换句话说,它们都被固定在自己的核心上。
  • 大约 60 个是中等优先级。
  • 大约 10 个是低优先级。

10 个最高优先级的线程一直在使用 cpu。

其余的都在做网络 IO 以及在 CPU 上做一些工作。问题是:我看到一个低优先级线程被饿死,有时一次超过 15 秒。此特定线程正在 TCP 套接字上等待某些数据。我知道数据已完全发送,因为我可以看到连接另一端的服务器已发送数据(即,它在发送数据后记录时间戳)。通常线程需要毫秒来接收和处理它,但偶尔会在其他服务器成功发送数据后需要 15 秒。请注意,增加线程的优先级并将其固定到 CPU 已经消除了这个问题,但这不是一个长期的解决方案。一开始我不会想到这种行为 - 15 秒是很长的时间。

有人知道为什么会这样吗?我们已经排除它是程序/线程中的任何逻辑。另请注意,该程序是用 C 编写的。

【问题讨论】:

  • 您可能(也)在 unix.stackexchange.com 上提问。你知道,如果你真的确定这不是关于“你的程序”,那么你的问题在这里实际上是题外话!

标签: linux multithreading pthreads starvation


【解决方案1】:

我一开始并不期望这种行为 - 15 秒是很长的时间。

如果您的 60 个中等优先级线程都可以运行,那么这正是您所期望的:使用实时线程,那么低优先级线程将不会运行根本,而有高优先级线程仍然可以运行。

您也许可以使用perf timechart 来准确分析发生了什么。

【讨论】:

  • 策略是循环的。我是否误解了优先级与 RR sched 政策的关系?
  • @rvishy1:听起来很像 - 请参阅 sched(7) 手册页。具有较高静态优先级的线程始终优先于具有较低静态优先级的线程运行 - “调度策略仅在具有相同静态优先级的可运行线程列表中确定排序。”SCHED_RR 是在这种情况下的政策)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-25
  • 1970-01-01
  • 2013-03-23
  • 1970-01-01
相关资源
最近更新 更多