同意，无人阅读的内容有何价值？又有谁会真正坐下来从头到尾读完 10,000 篇帖子呢？
有些话题作为随时间完全消失的短暂聊天是完全可以的，也就是我们之前所说的“快车道”与“慢车道”流量。
小型更新：
由于我们已报告并同意关闭所有超过阈值的项（并重新设定限制），性能似乎有所改善，而且改善显著。我们仍会遇到一些“由于极端负载，此内容暂时以未登录用户的视角向所有人展示”的提示，但频率已大幅降低。
在此说明：
- 感谢大家为优化那个庞大的数据表所做的辛勤工作，我们非常感激。
- 是否还有其他我们可能遗漏的“性能优化技巧”或“配置方案”？即使是“高级”建议，任何帮助我们都十分欢迎。
再次衷心感谢所有人的支持与反馈。
Postgres 12 将有所帮助，因为在 @falco 的测试中，它使表和索引的大小减少了 20%。
那件事有目标日期了吗？
我今天开始进行基准测试。
得先在 Meta 上运行一段时间，以便在全面推广前观察是否存在性能回归。
很抱歉再次提起这个问题，但这与 PostgreSQL 迁移是不同的问题（由于数据量过大，我目前还无法进行迁移）。
自从上次重建以来，我的数据库大小一直在不断增加：
上次重建是在 5 月 17 日，此后数据库大小持续上升，目前已达到 57.3GB，其中 post_timings 表占用了大量空间。
我主要担心的是，我正在尝试进行 PostgreSQL 更新（这将使索引大小减少 20%，但从长远来看无法解决此问题）。根据这里工作人员的评论，这种大小并不正常，因此它会持续增加，最终导致维护成本变得噩梦般高昂。时间越久，数据量越大，形成一个难以维护的恶性循环。因此，我核心问题依然存在：有什么办法可以解决 post_timings 表的问题吗？有没有什么可以删除的数据？
我可以压缩表吗？或者有其他方法？
感谢大家的帮助。
目前别无他法。如果您的论坛规模很大，其时间统计表也会很大。
Meta 是一个历史悠久的实例，但规模中等，其 post_timings 表仅为 4GB。另一方面，我们托管的一个实例不到 2 年，其 post_timings 表如今应已超过 100GB。
托管大型论坛确实会增加成本，而今天别无他法。
或许可以将数据库迁移到一台独立的 20 美元 Droplet（80GB 磁盘），并将 Web 服务放在另一台 10 美元的 Droplet 上？每月 30 美元的成本对于一个看起来相当大的社区来说似乎是合理的。
非常感谢你的帮助，@Falco。
好吧，是的，正如我所说，我只是想问问，因为在太空领域并没有“魔法”。我正在研究分区方案，但应用层可能会因为性能问题而变得太慢（说来话长，我正在记录测试结果，稍后会在这里展示给大家，如果其他人觉得有用的话可以借鉴）。
我按照之前问你的那样，进行了关于恢复备份等操作的测试，我认为这是一个可以利用的好机会，因为我立刻看到磁盘使用量减少了 30%（我仍在运行一些测试，以确认是否有遗漏的内容）。但现在，这种方法存在一个小问题。因此，尽管立竿见影的好处很大，但这也会引发一些问题（更不用说，我还不确定这些存储的图片是否被缓存，或者根本不起作用，是的，备份中确实包含了它们）。
我正在做笔记，以便更新原始帖子。我的想法是添加一系列简短的说明，供那些担心性能以及我目前所做的各种修改的人参考。
从技术角度来看，应用“自动删除回复”计时器是解决这一问题的良好方案吗？
这确实是个不错的主意，而且解决了可用性问题（因为正如我们所说，没人会去读 1 万条消息）。所以关键问题是，这会不会给服务器和数据库带来过大的负担。
我不确定一个包含 9000 条回复且其中约 8600 条被删除的话题是否会影响性能，但我对此表示怀疑。@eviltrout，你怎么看？
我原以为“隐藏”的帖子会在一段时间后从数据库中完全删除，但现在看来情况可能并非如此。因此，从性能角度来看，我的想法无法解决这个问题。
有什么方法可以“清除”这些数据吗？
已删除的帖子会被软删除。不过，它们通常仍会被搜索引擎索引，因此当您批量删除这些帖子时，可能会注意到一些改善。但我并不推荐这样做。如果有任何方法可以在某个话题变得庞大时将其迁移至新话题，那可能会对您更有帮助。
你这句话是什么意思？将数据库和 Web 应用部署在不同的服务器上应该能提升性能，因为虽然服务器之间会存在一些延迟，但你的 Unicorn 和 Postmaster 进程就不需要争抢 CPU 和内存资源了。
确保服务器位于同一个 DigitalOcean 区域哦 
抱歉，你说得对，这样两者都能释放出来，性能也会比全部放在单一实例上更好（我之前是拿单台机器上使用的资源以及到目前为止所做的优化在做比较）。
这确实是个非常好的主意，让我先试着解决我遇到的“无法重建数据容器”的问题，那将是我这段旅程中的下一个突破。
我一直在拼命搜索关于这个话题的内容，但找不到关于如何理想地实现这一点的文档。有这样的指南吗？
我们的标准单 VPS 安装也开始遇到瓶颈了。我们面临的独特困境是游戏聊天，这些聊天在冰球比赛期间进行，会导致活动/负载的急剧激增。特别是当比赛中发生非凡事件时。
我想，你需要某种足够强大的东西来应对最繁忙的时刻。或者，你需要在这些时段提升性能。或许可以寻找支持按小时付费的 VPS。一个解决方案（延续之前的建议）是：在有游戏活动时，将 Web 容器迁移到一台性能极强的 VPS 上，并仅在这些时段按小时付费。
您需要：
-
在其他地方运行 PostgreSQL（例如在 Droplet 上，或使用托管服务如 https://www.digitalocean.com/products/managed-databases/），并将您的数据迁移过去。
-
按照 在独立的 PostgreSQL 服务器上运行 Discourse 进行操作。
这也可以通过使用 Discourse 的容器化产品来实现吗？即 Web_only 和 data，对吗？
根据我的经验，目前没有任何方法能直接解决此问题，也不存在线性解决方案。事实上，将它们分离到不同的机器上并不能立即解决该问题。
我们也经历过类似的情况：当发生重大事件时（例如游戏活动，正如 @ljpp 所说），会出现严重的卡顿，并提示“站点极其繁忙，您正在以未登录身份查看”。这会导致整个站点性能下降，而不仅仅是该话题内的用户受到影响。
因此，我尝试了两种不同的方案：一种是独立部署，另一种是使用“大型机器”。但这两种方案都出现了类似问题。我的实例通过 Prometheus 进行监控，日志可通过 Grafana 等工具查看，因此我对硬件和容器的性能拥有非常细粒度的控制能力。我可以确认，无论您采取何种措施，问题依然会发生。
如果您在其后部署一台大型机器，或许能稍微延缓问题的出现，但最终仍会出现错误和会话中断，而且该机器的磁盘、CPU 或内存使用率几乎为零。这种情况在“默认安装”和“双容器安装”中均会发生。
使用不同机器时，问题依旧存在，无论这些机器是同一类型，还是分别配置为