互斥睡眠占用大量 CPU答案

【问题标题】：Mutex sleep is taking a lot of CPU互斥睡眠占用大量 CPU
【发布时间】：2023-12-30 14:23:01
【问题描述】：

我使用 ruby-prof 分析了我的基于事件机器的应用程序，发现以下有趣：

5.28 0.00 5.28 0.00 4/4 互斥#同步 90.72% 0.00% 5.28 0.00 5.28 0.00 4 互斥#sleep

我认为 ruby-prof 只计算 CPU 滴答数，因此我无法弄清楚为什么互斥锁睡眠可能会占用 CPU 时间。我假设它在内核级别上休眠，不计入光纤时间。有任何想法吗？更好的是，我希望 Mutex#sleep 将控制权释放给事件机器，以便它可以做其他事情。

【问题讨论】：

【解决方案1】：

如果 ruby-prof --mode=cpu 真的只是计算 CPU 时间，那么 Mutex#sleep 就是一个自旋锁：

这是有道理的，因为您只应该在互斥锁中包装非常短的分配。设置信号警报将是疯狂的开销。

因此，您面临的挑战是确定您所依赖的互斥体，以及它们包裹的内容。然后，您会发现可以避免的互斥体滥用或不可避免的等待时间。

【讨论】：

【解决方案2】：

据我所知，如果您在等待释放锁时被卡住，则该线程会卡在睡眠模式中。保持 Eventmachine 运行的唯一方法是确保您的锁发生在单独的线程中。

【讨论】：

【解决方案3】：

这 90% 可能意味着您有 90% 的时间都在“睡觉” [?] 一般来说，对于 EM，您不需要睡觉，您只需响应事件，大部分 CPU 将显示为EM 的“运行”方法

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

这里的信息太少，无法给出准确的答案，但是，我建议您查看其他一些方面，例如 ruby-prof 是否甚至会增加在反应器中花费的时间？

不管 ruby-prof 给你的百分比是多少，你的配置文件实际运行了多长时间，以及在互斥体中实际花费了多长时间？这很可能只显示#defer 线程或类似的东西，而完全忽略了另一个线程中的 C++ 运行时。

【讨论】：