经常看到 CPU 使用率很高，通常在 85% 左右：
之前显示为 unicorn.conf.r：
这是否表明 UNICORN_WORKERS 设置得过高/过低？
服务器有 64GB RAM（通常显示约 40GB 可用）和 6 核，服务器上有 4 个 Discourse 实例，每个实例都设置为 UNICORN_WORKERS: 8
有什么想法或建议可以找出原因或尝试什么吗？（其中一个论坛处于只读模式，流量不大，是否应该将其设置为较少的 worker？）
2 个赞
我不知道，但我打赌你使用的工人数远超你的核心数？
1 个赞
是的。我也建议减少独角兽工作进程的数量：
2 个赞
您可以尝试减少 Unicorn 工作进程的数量。
2 个赞
感谢大家的回复——我不确定现在在哪里读到的，但我一直认为我们应该为每个核心设置 2 个工作进程。我现在根据论坛的建议减少了工作进程，将更多的工作进程分配给最繁忙的论坛，将较少的工作进程分配给不太繁忙的论坛。我将在下周继续观察情况，如果问题没有解决，我会回来汇报。
编辑：我想我是在这里读到的。
1 个赞
在这种情况下，您并没有为每个核心分配两个工作进程。您有六个核心，这意味着十二个工作进程，但您有四个实例，每个实例使用八个工作进程，总共 32 个。
4 个赞
是的……我已经调整了，使工作进程总数不超过核心数的两倍，但我仍然想知道——正确的/标准的建议是什么，是你说的还是Nate的帖子里说的，他引用Jeff的话说每个核心一个工作进程？
根据我自己的实验，每个核心一个工作进程会导致超时（但会降低服务器负载），更多的进程会带来更好的性能但更高的负载（在我的服务器上仍然在可接受的范围内）。
1 个赞
请看 discourse-setup，它负责处理新安装的扩展：
# UNICORN_WORKERS: 2 * GB for 2GB or less, or 2 * CPU, max 8
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
第二个语句，使用可用核心数的两倍，是具有超过 2GB RAM 的系统上的默认设置。看起来您的问题更多是由于您的实例（主机资源）之间的争夺，而不是 discourse 问题。
2 个赞
在我上次升级后，我也看到了同样的情况，那是在 OP 之后一天，所以我认为这与独角兽工作进程的数量无关。unicorn.conf.r* 进程很可疑，因为这个主题的原始帖子是整个网络上关于该术语的唯一搜索结果。 我认为 unicorn.conf.rb 会更正常。
增加发生在正好是我上次升级的时候，也就是 4 天前。请注意，OP 是在 5 天前发布的。Discourse 中有什么东西改变了。
我在同一个实例上使用了相同数量的独角兽工作进程好几年了，什么都没改——只是重建到了 3.4.0.beta4-dev。
1 个赞
FWIW，sidekiq 中没有长时间运行或失败的作业。
1 个赞
我刚刚升级到了最新的 Discourse，再也没有看到 unicorn.conf.r*（现在任何接近 80% CPU 使用率的进程都是 ruby，但似乎不那么频繁了）。负载与之前大致相同（尽管比我调整 worker 之后要低）。
你升级到最新版本了吗？你使用的是什么类型的硬件，你的论坛有多繁忙？
是的，我使用的是 3.4.0.beta4-dev。正是这个版本开始出现高 CPU 使用率。其他什么都没变。
8 GB RAM，2 vCPUs，160 GB SSD，空间充足。
我上面发布了生产站点的 CPU 使用率，该站点同时在线用户约 30 人。但我有一个测试站点也存在同样的问题，而且那里绝对没有任何流量和插件。更新前后（峰值是每日备份）：
1 个赞
我不确定我们的情况是否有关联，马克。我认为在我的案例中，斯蒂芬所说的起到了很大作用：
我最近将另外两个实例迁移到了同一台服务器上，并且实际上忘记了 unicorn worker 设置为 8，因为以前我们使用的是核心更多的服务器（但它有自己的问题，因此我们回到了 Xeon，它的核心较少但整体性能更好）。
所以，我发现减少此服务器上的 unicorn worker 会降低负载，但会导致超时；增加它们可以消除超时，但会导致更高的负载——尽管仍在可接受的范围内。我认为我可以增加 worker，我们仍然可以处理增加的负载，但我们现在的情况暂时很好。
话虽如此，我已将实例迁移到同一台服务器上，并且它的运行符合我的预期（负载增加，但幅度不大），并且感觉更新导致了更高的负载……但我无法确定，我们必须记住，随着 Discourse 功能的不断增加，它可能需要更强大的硬件，或者有时会让人感觉“变慢”（我有一些旧版本的 Discourse 实例，它们感觉明显更流畅——当然，它们没有新版本的所有功能）。
话虽如此，我认为自最新的 Discourse 更新（使用 PG 15）以来，负载实际上略有下降。
我不知道该为您建议什么，马克——也许可以尝试调整 worker 和其他一些设置？例如 db_shared_buffers 和 db_work_mem？也许可以开一个专门的帖子，内容类似“更新后 CPU 使用率高 - 我的实例需要性能调整吗？”或者类似的东西 
1 个赞
我今晚进行了升级，并立即注意到我的网站的 CPU 使用率有所不同。这是升级前、升级中和升级后的图表。这代表了一小时的时间。
在 DO 上运行的标准 Discourse 单容器安装 - 8 GB RAM、2 个 vCPU 和 100 GB SSD，空间充足。
我们将看看 12 小时后的情况。
4 个赞
升级 15 小时后的结果如下。CPU 使用率已急剧增加 3 倍。负载系数增加了 4 倍。
| 最小值平均值 | 升级前 | 升级后 |
|---|---|---|
| 5 | .11 | .4 |
| 15 | .10 | .45 |
24 小时视图：
Java 是主要的 CPU 使用者。最近的升级中发生了剧烈变化。
Discourse 团队需要什么信息来排除故障？
这个话题是否应该移到 Bug？
2 个赞
所以看起来我的问题并不是 unicorn 工作进程——在 @sam 根据 @LotusJeff 的 帖子 进行更新后，服务器负载已恢复到之前的水平（不到峰值的一半）……
4 个赞
这也能解决我的问题。
1 个赞
如果我没有密切关注服务器，我可能根本不会注意到，因为我最近刚把另外两个论坛迁移到上面——我想知道有多少人在不知情的情况下受到了影响？
Discourse 团队是否制定了措施来提醒他们注意此类问题？也许可以有一个管理员可以为特定主题设置的志愿者计划，例如，“在升级前后 XX 小时/天/周内将服务器负载发送到 Discourse”。或者，最好是在本地跟踪这些问题，然后在升级后注意到服务器负载增加时提醒管理员——然后我们可以根据需要在此处发布。
1 个赞
我可能不会注意到这个影响，但由于我们大约两周前迁移到了 Discourse，我一直在密切监控服务器。我正在进行各种迁移后验证（备份运行等）。几个月后，我可能永远不会注意到这个影响。
我希望 Discourse 每天都有负载测试运行。在我以前的工作中，我有一个服务器每天都会用提交的代码进行重建。它有模拟用户一整天都在使用服务器。我们从用户和服务器的角度测量了关键性能指标。这使我们能够主动发现内存泄漏、低效代码和意外的用户体验更改。
我仍然要赞扬 Sam 和他的团队。从 phpBB 的时代过来，在那里类似这样的问题需要几十年才能解决和补救，我觉得这种快速响应非常棒。（即使这意味着要熬夜到堪萨斯城时间凌晨 2 点，而不是悉尼时间。）
2 个赞