我们已将所有调整过的值恢复为默认值，并更新至 2.6.0 beta4。周四和周五将有游戏上线，因此本周晚些时候我们将拥有良好的测试覆盖率。
很遗憾，该修复并未解决问题。我们有一个活跃度中等的游戏，包含 600 条消息。通过我本人的测试以及会员们的反馈，都观察到了多次冻结现象。这些冻结与游戏事件（即活跃度激增）相关联。
- CPU 使用率完全在限制范围内，峰值约为 60%，平均负载约为 30%。
- 这绝对是客户端问题。当聊天话题冻结时，如果你进入首页，会看到未读帖子的数量。点击返回该话题，帖子就会重新显示。
让我仍然困惑且本话题未涵盖的一点是：自 v2.3 以来发生了什么变化？v2.3 版本并没有这个问题。
重大更新 2.4 和 2.5 发生在我们（因疫情延长的）休赛期，因此没人注意到任何异常，但在季前第一场表演赛中，冻结现象立刻显现出来。
我们明天可以尝试哪些参数调整方案？那将是一场激烈的德比战和客场作战，社区氛围将会非常热烈。
在我们的案例中，关闭“在线用户”插件并停用速率限制文件（我了解到最近的测试版已有一些改进）似乎为我们解决了问题。
我们现在偶尔也会举办足球比赛，约有 300 名或稍多一些的用户在同一时间点击并在同一主题中发帖，而在最近的一场比赛中，系统表现明显更好。
您是否已升级到最新版本，并应用了 最近的修复？
请务必更新为“测试通过”。自 beta 版以来，我对相关内容做了大量优化。
是的，最新的 Beta 版本（即过去 48 小时内的版本）。
已更新。报告将随后发布。
很遗憾，仍然无法运行。当然，游戏过程非常激烈，产生了 950 条消息。我查看了 GAnalytics，当时约有 250 人在观看，其中 119 人发布了消息。和之前一样，出现了多次卡顿。消息总线返回了一些 429 错误，错误信息为“您执行此操作的次数过多，请等待 X 分钟”。
CPU 负载峰值约为 70%，而等待时间（wa）几乎为零。因此，尽管活动量很高，我们仍然无法提供硬件本应具备的性能。
能否请您回答一个一直困扰我的问题：在 2.3 版本之后实施了哪些功能导致了这个问题？这些功能本应带来什么改进？
实现方式与以往基本相同，只是我们新增了可配置的全局应用速率限制。如果您希望提高限制，可以自行调整，但这可能导致系统完全崩溃，我也不确定。
我不太明白您提到的“冻结”具体指什么。如果当前负载过高，更新会停止，但不同的是，您现在无需刷新浏览器即可恢复页面显示；一旦服务器具备处理能力，它会自动恢复。
这里有点不清楚：我的更改后，您的用户是否完全没有观察到任何改善？
您的服务器是否有大量空闲内存？如果有，请增加 Unicorn 工作进程。
您的 db_shared_buffers 参数设置是多少？起初我们遇到了很多“不稳定”的情况（某些话题“消耗”大量资源，尤其是在参与人数众多时），当时仅使用了推荐的总内存的 25%。当我们将其增加到 16GB（总内存为 32GB）后，所有不稳定性都消失了……最近，随着最新的更新，情况甚至变得更好了。
好的，这种现象在生产环境（游戏聊天）中很难监控，因为每个游戏都不同——关键事件的数量不同、对手不同、情绪强度不同，等等。
从我们的角度来看，问题在于自 2.3 版本以来，我们的最大服务能力下降了。这是关键点。每个服务器都有其极限，但现在我们服务器能发挥的效能比运行 2.3 版本的 3 月份要低。根据粗略的后端监控，服务器无法达到 100% 的负载或容量。
最终用户看到的是聊天流直接停止，且界面上没有任何提示说明发生了什么。这会引起困惑。
我相当确信，测试通过的改进已经改善了现状，但性能或最大输出仍然显著低于 2.3 版本。
我们有一台 VPS，配备 6 个快速核心和 16GB 内存。Unicorn 进程数设置为 12，与内存缓冲相关的设置均为默认值。
我认为接下来最好的步骤是设置系统的历史监控，以便我们找出瓶颈所在，因为我们已经确定问题不在于 CPU 时间。您有可能达到了网络连接的极限！
此外，还可以结合使用更传统的服务器指标，例如 node-exporter。
如果情况确实如此，而您希望进一步提升负载，可以尝试以下方法：
-
降低速率限制，这将允许用户更积极地与 Discourse 进行交互。具体来说，您可以将
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE和DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS的值翻倍。 -
尝试增加更多的 Unicorn 工作进程。
在您服务器过载期间，这种情况是暂时且预期的；一旦负载降低，系统应会自动恢复。
我的猜测是，这全部与速率限制有关。这些速率限制是新增的，旨在保护服务器，看来您的服务器正按设计被保护着。
我们尝试了一场游戏，配置如下：
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none……然而，当第三局情绪开始升温时，情况急转直下。我们的服务器达到了极限，用户不断被强制“登出”，游戏聊天室也出现了冻结。
过去四年这曾是一段成功的历程，但现在我们陷入了非常棘手的境地。升级到下一档 VPS 配置将使我们进入约 160 欧元/月的价格区间，这对一个爱好者站点来说是个不小的挑战。我们谈论的也不是庞大的用户量——仅有 116 人在游戏期间发布了 800 多条消息。
“不要聊天”的理念也不适用。如果没有这些聊天功能，情绪化的反应帖就会散落在各个更“严肃”的话题中。它们是将实时情境中的情绪能量集中引导到单一话题的重要工具，从而保持分析性话题的整洁。
我运营的是一个足球论坛，也遇到过类似的挑战。
总的来说，我发现这是一个可扩展性问题。
对我而言，问题在不同层级显现出来。
Digital Ocean：
- 1 核 CPU + 1 GB 内存：在类似聊天的场景下可支持 30–40 名用户。
- 2 核 CPU + 2 GB 内存：在类似聊天的场景下可支持 70–80 名用户。
- 4 核 CPU + 8 GB 内存：可轻松应对 120 名用户，并在 2 小时内处理 1000 条帖子，尚未触及上限。
我目前正在尝试通过 Hetzner（镜像站点）升级不同层级，因其价格更便宜，但进展不如预期顺利。
我目前的经验是：
- 3 核 CPU（CPX 21，AMD 芯片）+ 4 GB 内存：20 名用户时已显吃力。
- 2 核 CPU（Intel）+ 8 GB 内存：20 名用户时运行正常，无问题。
接下来我计划在比赛条件下测试 80 至 100 名并发用户。
当我查看 Digital Ocean 的 CPU 使用情况时，即使在压力测试下，各层级的 CPU 使用率始终保持在较低水平，从未超过 50%。
而在 Hetzner 上查看 AMD 芯片的 CPU 使用情况时，我看到中位 CPU 使用率约为 60%，但每隔一分钟左右就会出现短暂峰值，最高可达 CPU 使用率的 300%。这种现象在 Intel 芯片上并未出现。
这意味着什么，我尚不清楚。我怀疑 Hetzner 的 CPU 监控更为精准（能够捕捉到短暂峰值）。但整体来看，CPU 使用率似乎较为均衡。从表面看，Digital Ocean 似乎更能应对峰值负载，但本周末之后，我应该能获取更多关于 Hetzner 的信息。
我还想补充一点，在 Hetzner 测试中，Whose Online 插件并未产生任何影响。
但 Discourse 的快速消息插件似乎带来了负面影响。
下一场游戏将于明天举行。我们已经移除了自己的临时方案，正在尝试使用这些设置。
此外，作为一个完全碰运气的尝试，我将 db_shared_buffers 从 4GB（25%）增加到 6GB（37.5%）。我还取消了 app.yml 中 db_work_mem 40MB 这一行的注释（顺便提一下，这是一个文档非常模糊的选项，尽管在管理员界面中仍被呈现为某种优化机会）。
我不再指望能找到问题的根本解决方案，而只能寻求更好的止损措施——即一组对最终用户体验负面影响最小的参数。在此期间，我必须进一步探索增加我们托管资源的可能性。
@sam 及其他开发者，有个问题想请教。
数据库规模持续增大会如何影响这一使用场景？即用户在几个小时内频繁访问单个主题。
我查看了历史游戏聊天活动，发现早在 2017 年，当时我们的服务器资源仅为现在的零头，却已出现过统计数据庞大的游戏。有的游戏帖子数量高达 1600 条，涉及 165 名用户，但当时并未有人抱怨性能问题。如今，即便服务器性能强大得多，我们却连一半的负载都无法承载。
你可以尝试将其提高到 80MB。也许可以替代其他更改。
这是我们一直在积极投入的一个重点。
Discourse 刚推出时，几乎所有站点都使用全新的数据库，因此数据库可以轻松放入内存。然而几年后的今天，一些站点的数据库大小已超过 100GB，而内存容量甚至不足其十分之一。
未来几周内即将推出的一个更新是 PostgreSQL 13 升级，该升级将把最大对象的大小减少一半。
除此之外，调试性能问题的第一步是使用 Discourse 的 Prometheus 导出器插件 收集数据，这样我们就能有的放矢，而不是盲目摸索。