您好，
我刚安装了 Ubuntu 20、Docker 和 Discourse。我没有添加任何插件，数据库中只有两个用户，但构建却需要 40 多分钟才能完成！构建过程没有哪个特定部分很慢，整个过程都极其耗时。这是一台配置相当不错的服务器，我还有另一台服务器可以很好地为 20 个客户的网站提供服务，所以这并非性能问题。
在此处挂起至少 4 分钟：
warning Resolution field "lodash@4.17.21" is incompatible with requested version "lodash@4.17.15"
在此之后立即再次挂起 4-5 分钟：
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
我尝试使用 --skip-prereqs 进行构建，但无济于事，每次重建仍需 40 多分钟。
您认为有什么特别的原因可能导致这个问题吗？
感谢您的帮助。
我也注意到重建也花费了很长时间。你有多少内存？
我重建了我的 DO 实例（1 GB 内存 / 25 GB 磁盘 / LON1 - Ubuntu 20.04 (LTS) x64）
耗时 20:25,44
CPU 如预期般飙升
内存表现随机
带宽出乎意料
4GB 内存 
感谢更新 @Falco
感谢您的确认@Falco，我这里是1GB内存（很紧张但对于一个轻量级网站来说从未需要更多）。现在需要超过30分钟才能构建（通常大约需要10分钟）。
Rafael，这是2.9.0 beta还是2.8.0 stable的回归问题吗？
回到第一个帖子，有人知道这个警告来自哪里吗？
我不知道这是否真的值得考虑，但就我个人而言，在许多事情上我都注意到在使用 Ubuntu 20.04 时性能会下降（Discourse、Web 服务器、游戏服务器），即使尝试了不同的优化方法 
目前，我在一个 Droplet 中运行 Discourse 进行测试，其配置相同，重建大约需要 8-12 分钟（Ubuntu 18）
构建时间还取决于您安装了多少插件和主题组件。
这也需要时间来重建。
由于我加载了所有官方插件，因此我的构建时间会稍长一些。
我知道，但在这里我指的是规格的“相等性”，也就是说，没有插件也是如此
我不认为构建在这些警告处会“挂起”。它只是在静默构建，警告是作为过程的一部分输出的。
也就是说，警告或其根本问题并不会导致构建时间过长。
我们可以在哪里跟踪这个问题@Falco？ 感谢您告知我们此事，我刚刚才发现，这给我们造成了很大的困扰。
这是我们多年来一直在进行的一项巨大变革，目前正进入最后阶段。在此期间，我们会经历一个“在好转之前会先变糟”的阶段，而这正是“变糟”的副作用之一。
一旦我们为所有现有站点完成 新安装将默认使用 Ember CLI 构建进行生产 并移除旧的资产管道，我们就可以积极地开始对其进行现代化改造，并希望能获得一些上游收益。
我们还有可能允许使用慢速 CPU 的用户选择退出源映射和其他“锦上添花”的功能，以加快他们的重建速度。
感谢您的更新@Falco 
我在 Linode 上使用四核 CPU 和 8GB RAM，这通常是一个很棒的设置，但现在却是一场噩梦。我们有一些计划要做出的更改，但现在必须等到部署恢复正常的速度。
@Falco 我也注意到，在最近几次发布中，服务器性能有所下降，加载网站需要更长的时间，并且消耗更多内存。在过去两年里，我的设置（插件、硬件等）没有任何变化，网站的活跃用户数量也保持不变。是否有办法从 Discourse 内部客观地监控网站性能，以便我们在此处反馈？目前我唯一知道的方法是，当我打开网站时，第一次加载需要超过 8 秒（早期版本总是可以在 2-3 秒内完成）。
你们看到的是什么样的重建时间？我只是因为 SMTP 更改需要重建，对于一个很小的网站（30 个用户，400 篇帖子），花费了将近 12 分钟。
此主题是关于“构建时间”，而不是关于加载页面时间。如果您讨论的是页面响应时间下降，请提供一些数据并另开一个新主题。
今天早上的最后一次构建大约花了 20 分钟
谢谢，在今天的更新之后，页面加载时间已恢复到正常的 2-3 秒（惊喜！）。
哎哟，这不正常。
我想我已经弄清楚为什么页面加载这么慢了。app.yml 中的共享数据库大小被设置为等于系统的总内存。将其重置回默认值（25%），重建后现在不到一秒了。
