跟进此帖子：Slow Page Loads on User Profiles
在应用这些更改后，我们再次测试了向 Discourse 的导入。个人资料加载有所改善（尤其是初始加载后数据已缓存在缓存中时），但某些个人资料的加载仍需 5-10 秒。是否还有其他措施可以进一步优化？这些似乎是导致问题的查询：
你是如何安装 Discourse 的？
1 个赞
按照说明安装 Docker 容器。
1 个赞
需要多少内存？数据库有多大？
1 个赞
这台虚拟机拥有 8 个核心和 32 GB 内存。我认为数据库大小约为 40 GB，但目前还无法完全确定。
1 个赞
如果发生以下情况，缓慢的个人主页加载问题是否仍然存在：
- 以匿名用户（未登录）身份查看用户个人主页？
- 查看普通用户与工作人员用户的个人主页时？
2 个赞
是的，两者皆是。我用普通用户测试过，并退出登录，表现大致相同。
恢复后，数据库大小现已达到 104 GB。
该主题主要涉及我们在那个路由上存在的多个 N+1 查询问题，这些问题现在都已修复。
个人资料页面确实包含一些重量级查询，因为它会输出非常个性化且完整的用户摘要，但对于规模合理的数据库来说，渲染时间应能在 500 毫秒以内。
对于小型虚拟机来说，这是一个很大的数据库。您是否将所有服务（Web+DB+Redis）都运行在同一台虚拟机上？
您是否运行了最新的 PostgreSQL 13？能否尝试运行 PostgreSQL 13 更新 中描述的可选性能任务，包括 vacuum 和 reindex？
3 个赞
遇到问题的用户都是发帖量很大的用户。发帖量少的用户的个人资料页面则如预期那样立即加载。
也许我需要在这里调整一下我的期望。对于 Discourse 来说，8 核 CPU 和 32 GB 内存算小吗？（是的，我们是以单容器方式运行的。）在我们当前的软件上，用 2 核 CPU 和 8 GB 内存就能轻松运行这个论坛。
至于数据库，它是一个新构建的容器，因此是从 13.1 版本开始的。在恢复之后立即执行 vacuum 和 reindex 是必要的吗？
1 个赞
对于如此规模的数据库，强烈建议执行 VACUUM。
3 个赞
我在你发帖后不久就开始执行这些操作。真空操作很快完成，但重新索引仍在进行中，从开始到现在已超过 24 小时。这正常吗？预计需要多长时间？如何判断是否有资源（如果有）受限？我注意到 postmaster 大部分时间仅占用 2-4 个核心，且似乎有大量可用内存。
1 个赞
很遗憾地通知您，重新索引仍在进行中。
@Falco @codinghorror @pfaffman
过去一年来，@Ghan 和我一直在努力完善并确保导入功能适用于我们的社区，但我心中始终有一个问题：在导入一个拥有超过 2500 万帖子的社区时，我们是否还需要考虑其他因素？
Discourse 上是否存在如此大规模的社区？
我查看了公开的客户列表，从我能看到的部分来看，似乎没有谁的规模接近我们。不过我猜，可能还有成千上万个我看不到的客户。我们已经成功完成了导入，在我们这边运行正常，但我们不断遇到一些问题，例如帖子数量庞大的账户导致的个人资料加载问题，以及现在的重新索引问题。
能否给我们一些建议，帮助我们更顺利地完成这次过渡？
1 个赞
是的，正如我在另一个主题中提到的，我们有一些数据库大小为 1GB 的实例，也有一些数据库大小为 500GB 的实例。但这些实例运行在配置完全不同的虚拟机上。
您服务器的磁盘性能如何？是否使用的是老旧的机械硬盘？
2 个赞
主机服务器上配置了两块 1.2 TB 的 Intel P3600 NVMe SSD，采用 ZFS 镜像模式。
2 个赞
接下来要检查的是 PostgreSQL 调优。您在 app.yml 中使用的是默认配置吗？
1 个赞
是的。我不确定启动器是否会基于主机上检测到的资源自动设置某些值，或者是否有推荐的调优指南。是否有数据库调优的相关指南？
app.yml 中有一些注释，但该文件主要是针对小型自托管站点进行优化的。你可能需要调大其中的某些设置（我记不清具体名称了）。你需要查阅一些更通用的 PostgreSQL 资料以获取更多信息。
Discourse 并非无法承载你这样规模的社区，只是与运营小型社区有所不同，且会稍微复杂一些。
3 个赞
谢谢，我肯定会去看看。我对 PostgreSQL 不太熟悉，但希望多年来运行 MySQL 所积累的原则能够适用。
确实如此。我觉得一旦我们能明确需要进行哪些类型的更改，事情就会顺利得多。
3 个赞