自本周末升级以来，我注意到 CPU 使用率大幅增加。RUBY 的 CPU 使用率似乎是主要原因。另一位 Discourse 用户在此主题中也提到了这一点。
从下面的图表中可以看出，升级前 CPU 使用率和负载远低于升级后。升级发生在 1 月 31 日晚上。
以下是间隔 33 小时的两个 TOP 图像：
在 33 小时内，ruby 的 CPU 使用率显著增加。根据 top 数据，在过去的 33 小时内，我的 CPU 使用率是 22 天的 2 倍。在 33 小时内，我看到了 11 小时的 CPU 时间。（5 个 PID 共计 648 分钟的 CPU 时间）
附加数据：
这种情况并非服务器宕机，但运行在 5% 到 7% 的服务器比运行在 25% 的服务器要好得多。
我能提供哪些信息来协助排查此问题？
提前致谢
让我们先将其留给支持部门处理，直到我们确定是否存在 bug。
您可以进入容器并在内部运行 htop（您需要安装它），这样您就可以知道是哪个特定进程占用了大量 CPU。
您可以使用类似这样的技术获得更多可见性：Debugging 100% CPU usage in production Ruby on Rails systems
但最有可能的是，您的实例上的 sidekiq /sidekiq 负载过重。（我尤其会关注调度器）
有什么不对劲：
top -H -p PID_OF_UNICORN
我怀疑你会看到 V8 DefaultWorker，我认为这是 mini_racer 的一个回归……我会将其恢复，看看是否能解决这个问题。
是的，它解决了高 CPU 问题。我的 1 分钟和 5 分钟负载大约是之前值的三分之一。这是在 htop 和 netdata 仍在系统上运行时测得的。
随着更多数据库查询被缓存到系统中，我预计 CPU 使用率和负载会缓慢下降。
| 时间 | 修复前 | 修复后 |
|---|---|---|
| 1 分钟 | 0.4 至 0.6 | 0.06 至 0.1 |
| 5 分钟 | 0.39 至 0.5 | 0.15 至 0.18 |
15 分钟指标受到重建的影响。我将在今天上午晚些时候发布更多统计数据。
感谢您深夜修复。
抱歉，mini_racer 的升级是一次大冒险。希望我们很快能顺利完成。
感谢您迅速响应进行调查。
我相信您今天还有其他计划，而不是进行回滚。
作为一名新的 Discourse 用户，迁移至今已有两周，这款产品非常棒。
重建后 18 小时的性能审查。负载表说明了一切。
| 时间 | 修补前 | 修补后 |
|---|---|---|
| 1 分钟 | 0.4 至 0.6 | 0.03 至 0.05 |
| 5 分钟 | 0.39 至 0.5 | 0.09 |
| 15 分钟 | 0.68 | 0.12 |
图例：
请注意，问题的根源是这个 bug：
我已经更新了 gem。一个直接的好处是，这个版本的 v8 似乎占用的内存略少，这很好。
我昨晚安装了包含修复程序的最新版本。CPU 使用率已恢复到历史水平。
感谢您所做的所有出色工作。
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
