# 实时更新主题在高活动下冻结 **URL:** \ **Category:** Support\ **Created:** [2020年十月9日 16:28 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789 "2020-10-09T16:28:26Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月20日 19:06 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/22 "2020-10-20T19:06:18Z")
我们已将所有调整过的值恢复为默认值，并更新至 2.6.0 beta4。周四和周五将有游戏上线，因此本周晚些时候我们将拥有良好的测试覆盖率。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月22日 18:14 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/23 "2020-10-22T18:14:35Z")
@sam 很遗憾，该修复并未解决问题。我们有一个活跃度中等的游戏，包含 600 条消息。通过我本人的测试以及会员们的反馈，都观察到了多次冻结现象。这些冻结与游戏事件（即活跃度激增）相关联。 - CPU 使用率完全在限制范围内，峰值约为 60%，平均负载约为 30%。 - 这绝对是客户端问题。当聊天话题冻结时，如果你进入首页，会看到未读帖子的数量。点击返回该话题，帖子就会重新显示。 让我仍然 **困惑** 且本话题未涵盖的一点是：自 v2.3 以来发生了什么变化？v2.3 版本并没有这个问题。 重大更新 2.4 和 2.5 发生在我们（因疫情延长的）休赛期，因此没人注意到任何异常，但在季前第一场表演赛中，冻结现象立刻显现出来。 我们明天可以尝试哪些参数调整方案？那将是一场激烈的德比战和客场作战，社区氛围将会非常热烈。 ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年十月22日 18:36 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/24 "2020-10-22T18:36:34Z")
在我们的案例中，关闭“在线用户”插件并停用速率限制文件（我了解到最近的测试版已有一些改进）似乎为我们解决了问题。 我们现在偶尔也会举办足球比赛，约有 300 名或稍多一些的用户在同一时间点击并在同一主题中发帖，而在最近的一场比赛中，系统表现明显更好。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月22日 19:15 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/25 "2020-10-22T19:15:18Z")
> [@Paracelsus](#): > > 停用速率限制文件 您是否已升级到最新版本，并应用了 [最近的修复](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/11?u=ljpp)？ ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2020年十月22日 19:16 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/26 "2020-10-22T19:16:59Z")
> [@ljpp](#): > > 明天有什么参数技巧可以试试吗？这将是一场激烈的德比战，而且是客场作战，社区肯定会沸腾起来。 请务必更新为“测试通过”。自 beta 版以来，我对相关内容做了大量优化。 ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年十月23日 07:38 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/27 "2020-10-23T07:38:21Z")
> [@ljpp](#): > > > [@Paracelsus](#): > > > > 停用速率限制文件 > > 你使用的是包含 [最新修复](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/11?u=ljpp) 的最新版本吗？ 是的，最新的 Beta 版本（即过去 48 小时内的版本）。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月23日 09:56 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/28 "2020-10-23T09:56:13Z")
已更新。报告将随后发布。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月23日 18:20 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/29 "2020-10-23T18:20:34Z")
@sam 很遗憾，仍然无法运行。当然，游戏过程非常激烈，产生了 950 条消息。我查看了 GAnalytics，当时约有 250 人在观看，其中 119 人发布了消息。和之前一样，出现了多次卡顿。消息总线返回了一些 429 错误，错误信息为“您执行此操作的次数过多，请等待 X 分钟”。 CPU 负载峰值约为 70%，而等待时间（wa）几乎为零。因此，尽管活动量很高，我们仍然无法提供硬件本应具备的性能。 能否请您回答一个一直困扰我的问题：在 2.3 版本之后实施了哪些功能导致了这个问题？这些功能本应带来什么改进？ ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2020年十月23日 20:59 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/30 "2020-10-23T20:59:59Z")
实现方式与以往基本相同，只是我们新增了可配置的全局应用速率限制。如果您希望提高限制，可以自行调整，但这可能导致系统完全崩溃，我也不确定。 我不太明白您提到的“冻结”具体指什么。如果当前负载过高，更新会停止，但不同的是，您现在无需刷新浏览器即可恢复页面显示；一旦服务器具备处理能力，它会自动恢复。 这里有点不清楚：我的更改后，您的用户是否完全没有观察到任何改善？ 您的服务器是否有大量空闲内存？如果有，请增加 Unicorn 工作进程。 ---
**Author:** ![Paracelsus](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/paracelsus/32/164912_2.png) [@Paracelsus](https://meta.discourse.org/u/Paracelsus)\ **Post date:** [2020年十月23日 21:34 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/31 "2020-10-23T21:34:31Z")
您的 db\_shared\_buffers 参数设置是多少？起初我们遇到了很多“不稳定”的情况（某些话题“消耗”大量资源，尤其是在参与人数众多时），当时仅使用了推荐的总内存的 25%。当我们将其增加到 16GB（总内存为 32GB）后，所有不稳定性都消失了……最近，随着最新的更新，情况甚至变得更好了。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月24日 07:11 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/32 "2020-10-24T07:11:20Z")
> [@sam](#): > > 我不明白你说的“冻结”是什么意思。 好的，这种现象在生产环境（游戏聊天）中很难监控，因为每个游戏都不同——关键事件的数量不同、对手不同、情绪强度不同，等等。 从我们的角度来看，问题在于 **自 2.3 版本以来，我们的最大服务能力下降了** 。这是关键点。每个服务器都有其极限，但现在我们服务器能发挥的效能比运行 2.3 版本的 3 月份要低。根据粗略的后端监控，服务器无法达到 100% 的负载或容量。 最终用户看到的是聊天流直接停止，且界面上没有任何提示说明发生了什么。这会引起困惑。 我相当确信，测试通过的改进已经改善了现状，但性能或最大输出仍然显著低于 2.3 版本。 我们有一台 VPS，配备 6 个快速核心和 16GB 内存。Unicorn 进程数设置为 12，与内存缓冲相关的设置均为默认值。 ---
**Author:** ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)\ **Post date:** [2020年十月24日 12:46 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/33 "2020-10-24T12:46:47Z")
我认为接下来最好的步骤是设置系统的历史监控，以便我们找出瓶颈所在，因为我们已经确定问题不在于 CPU 时间。您有可能达到了网络连接的极限！ > [@Discourse Prometheus](https://meta.discourse.org/t/prometheus-exporter-plugin-for-discourse/72666): > > discourse2Summary Discourse Prometheus is the official [Prometheus](https://prometheus.io/) exporter for Discoursehammer_and_wrenchRepository Link [https://github.com/discourse/discourse-prometheus](https://github.com/discourse/discourse-prometheus)open_bookInstall Guide [How to install plugins in Discourse](https://meta.discourse.org/t/install-plugins-in-discourse/19157) The Discourse Prometheus plugin collects key metrics from Discourse and exposes them in the /metrics path so prometheus can consume them. These metrics can be used to Graph all sorts of data like: Median and 99th percentile time… 此外，还可以结合使用更传统的服务器指标，例如 node-exporter。 ---
**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\ **Post date:** [2020年十月26日 02:43 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/35 "2020-10-26T02:43:28Z")
> [@ljpp](#): > > 我们目前的产出比 3 月份要少，当前运行的是 2.3 版本。根据粗略的后端监控，服务器无法达到 100% 的负载或容量。 如果情况确实如此，而您希望进一步提升负载，可以尝试以下方法： 1. 降低速率限制，这将允许用户更积极地与 Discourse 进行交互。具体来说，您可以将 `DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE` 和 `DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS` 的值翻倍。 2. 尝试增加更多的 Unicorn 工作进程。 > [@ljpp](#): > > 最终用户看到的现象是聊天流直接停止，但界面上没有任何关于发生什么的提示。这导致了困惑。 在您服务器过载期间，这种情况是暂时且预期的；一旦负载降低，系统应会自动恢复。 我的猜测是，这全部与速率限制有关。这些速率限制是新增的，旨在保护服务器，看来您的服务器正按设计被保护着。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月28日 19:22 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/36 "2020-10-28T19:22:26Z")
我们尝试了一场游戏，配置如下： ```plaintext DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3 DISCOURSE_MAX_REQS_PER_IP_MODE: none ``` ……然而，当第三局情绪开始升温时，情况急转直下。我们的服务器达到了极限，用户不断被强制“登出”，游戏聊天室也出现了冻结。 过去四年这曾是一段成功的历程，但现在我们陷入了非常棘手的境地。升级到下一档 VPS 配置将使我们进入约 160 欧元/月的价格区间，这对一个爱好者站点来说是个不小的挑战。我们谈论的也不是庞大的用户量——仅有 116 人在游戏期间发布了 800 多条消息。 “不要聊天”的理念也不适用。如果没有这些聊天功能，情绪化的反应帖就会散落在各个更“严肃”的话题中。它们是将实时情境中的情绪能量集中引导到单一话题的重要工具，从而保持分析性话题的整洁。 ---
**Author:** ![Alec](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/alec/32/137283_2.png) [@Alec](https://meta.discourse.org/u/Alec)\ **Post date:** [2020年十月29日 05:10 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/37 "2020-10-29T05:10:20Z")
我运营的是一个足球论坛，也遇到过类似的挑战。 总的来说，我发现这是一个可扩展性问题。 对我而言，问题在不同层级显现出来。 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 的信息。 ---
**Author:** ![Alec](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/alec/32/137283_2.png) [@Alec](https://meta.discourse.org/u/Alec)\ **Post date:** [2020年十月29日 05:14 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/38 "2020-10-29T05:14:51Z")
我还想补充一点，在 Hetzner 测试中，Whose Online 插件并未产生任何影响。 但 Discourse 的快速消息插件似乎带来了负面影响。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月30日 09:28 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/39 "2020-10-30T09:28:45Z")
> [@sam](#): > > 你可以降低速率限制，这将允许用户更频繁地与 Discourse 进行交互。具体来说，你可以将 `DISCOURSE_MAX_REQS_PER_IP_PER_MINUTE` 和 `DISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS` 的值翻倍。 下一场游戏将于明天举行。我们已经移除了自己的临时方案，正在尝试使用这些设置。 此外，作为一个完全碰运气的尝试，我将 `db_shared_buffers` 从 4GB（25%）增加到 6GB（37.5%）。我还取消了 `app.yml` 中 `db_work_mem` 40MB 这一行的注释（顺便提一下，这是一个文档非常模糊的选项，尽管在管理员界面中仍被呈现为某种优化机会）。 我不再指望能找到问题的根本解决方案，而只能寻求更好的止损措施——即一组对最终用户体验负面影响最小的参数。在此期间，我必须进一步探索增加我们托管资源的可能性。 ---
**Author:** ![ljpp](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ljpp/32/96506_2.png) [@ljpp](https://meta.discourse.org/u/ljpp)\ **Post date:** [2020年十月30日 20:16 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/41 "2020-10-30T20:16:45Z")
@sam 及其他开发者，有个问题想请教。 数据库规模持续增大会如何影响这一使用场景？即用户在几个小时内频繁访问单个主题。 我查看了历史游戏聊天活动，发现早在 2017 年，当时我们的服务器资源仅为现在的零头，却已出现过统计数据庞大的游戏。有的游戏帖子数量高达 1600 条，涉及 165 名用户，但当时并未有人抱怨性能问题。如今，即便服务器性能强大得多，我们却连一半的负载都无法承载。 ---
**Author:** ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)\ **Post date:** [2020年十月30日 21:59 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/42 "2020-10-30T21:59:19Z")
> [@ljpp](#): > > 我也从 app.yml 中取消注释了 db\_work\_mem 40MB 这一行。 你可以尝试将其提高到 80MB。也许可以替代其他更改。 ---
**Author:** ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)\ **Post date:** [2020年十月31日 03:33 UTC](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789/43 "2020-10-31T03:33:19Z")
这是我们一直在积极投入的一个重点。 Discourse 刚推出时，几乎所有站点都使用全新的数据库，因此数据库可以轻松放入内存。然而几年后的今天，一些站点的数据库大小已超过 100GB，而内存容量甚至不足其十分之一。 未来几周内即将推出的一个更新是 PostgreSQL 13 升级，该升级将把最大对象的大小减少一半。 除此之外，调试性能问题的第一步是使用 [Discourse 的 Prometheus 导出器插件](https://meta.discourse.org/t/prometheus-exporter-plugin-for-discourse/72666) 收集数据，这样我们就能有的放矢，而不是盲目摸索。 [上一頁](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789.md?page=1) [下一頁](https://meta.discourse.org/t/real-time-updating-of-topics-freezes-under-high-activity/166789.md?page=3)