互斥睡眠占用了大量的CPU

我用ruby-prof描述了我的基于事件机器的应用程序，发现了以下有趣内容： 5.28 0.00 5.28 0.00 4/4 Mutex＃synchronize 90.72％0.00％5.28 0.00 5.28 0.00 4 Mutex＃sleep 我认为ruby-prof只计算CPU滴答，因此我无法弄清楚为什么互斥锁睡眠会占用CPU时间。我假设它在内核级别上休眠而不计算光纤时间。有任何想法吗？更好的是，我希望Mutex＃sleep能够释放对事件机器的控制权，所以它可以做其他事情。

已邀请:

5 个回复

久坡

如果ruby-prof --mode = cpu实际上只占用CPU时间，那么Mutex #sleep是一个自旋锁： http://en.wikipedia.org/wiki/Spinlock 这是有道理的，因为你只应该在互斥锁中包含非常短的赋值。设置信号警报将是疯狂的开销。因此，您面临的挑战是确定您正在睡觉的互斥锁，以及它们包装的内容。然后，你要么发现可以避免的互斥滥用，要么发现不可避免的等待时间。

壬驴拿歪竞

据我所知，如果您等待锁定释放，该线程将陷入睡眠模式。保持Eventmachine运行的唯一方法是确保锁定发生在单独的线程中。

捐焦

那90％可能意味着你90％的时间都在“睡觉”[EM]一般情况下你不需要睡觉，你只需要回应事件，而且大多数cpu会显示为EM的“运行” “ 方法

镰茧钩

通常，如果一个线程正在做某事而第二个线程正在等待它完成，那么它将被视为正在休眠。所以你的睡眠时间可以是（取决于你的线程）： - 你的线程正在等待一个事件（空闲） - 你的那里正在等待另一个线程完成某事（其他线程忙）

唤副埂侧壬

这里提供的信息太少，无法给出准确的答案，但是，我建议您考虑其他一些方面，例如ruby-prof是否甚至花费了在反应堆中花费的时间？无视ruby-prof给你的百分比，你的个人资料实际运行了多长时间，以及实际花费多长时间在互斥体上？它可能只显示#defer线程或类似的东西，完全忽略了另一个线程中的C ++运行时。

要回复问题请先登录或注册

互斥睡眠占用了大量的CPU

5 个回复

发起人

mutex

eventmachine

ruby_prof

问题状态

互斥睡眠占用了大量的CPU

与内容相关的链接

5 个回复

发起人

mutex

eventmachine

ruby_prof

问题状态