我的重建大约需要 10 分钟。我认为以前大约是 5 分钟。所以没什么大不了的。不过错误消息是什么意思？我收到了与上面原始帖子中类似的消息：
I, [2022-06-20T21:41:47.107238 #1] INFO -- : cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'
warning "eslint-config-discourse > eslint-plugin-lodash@7.1.0" has unmet peer dependency "lodash@>=4".
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".
我也要在此基础上添加更多内容。我运行的是一个精简系统（1GB内存）和一个小型网站。它有两个 unicorn 工作进程，每个进程占用了 30% 的内存，这导致了大量的内存颠簸，因此我决定将数量从 2 个减少到 1 个（我相信每个进程可以处理大约 10 个并发连接）。这带来了巨大的改变，使页面加载几乎瞬时完成，并将交换量减少了 5-10 倍（取决于加载的内容）。
我目前看到的缺点是，我无法再通过浏览器升级来更新 discourse。当我尝试通过浏览器更新时，我会收到：
ABORTING, you do not have enough unicorn workers running
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: Not enough workers>
所以这只是一个需要注意的地方，不确定 Discourse 团队是否能够解决——即在只有一个 unicorn 工作进程的情况下进行浏览器升级。
这似乎是一个错误，尤其是因为系统很快就会暂时减少到一个独角兽。
数字 2 是硬编码的，减少的数字 1 也是硬编码的。
编辑：看起来这个更改引入了不一致
我认为您的帖子（以及此回复）应该在新主题中，在 bug 类别下。
这如何运作？
一个 Unicorn 来处理升级过程，而其余的则处理正在进行的调用？
因此，需要最少 2 名 Unicorn 工作人员来执行在线升级……？
这是错误的。单个 unicorn 一次只能处理一个请求，因此虽然可供小团体使用，但我们不建议大多数网站使用它。
@Falco 我查看了其他管理员的数据。我的理解是，每个 Unicorn 会为每个传入连接分叉一个新进程。因此，虽然技术上一次只有一个连接，但每个 unicorn 可以处理多个并发用户。
根据下面分享的经验，大约 8 个 Unicorn 可以处理大约 400 个并发用户
根据这一点，每个 unicorn 可以处理大约 50 个并发用户。现在我知道 RAM 和系统资源会影响可以分叉的数量等，因此我假设 1 个 Unicorn 工作进程可以在低端 RAM 系统（1 GB）上处理 10 个并发用户。
我的假设+结论完全离谱吗？如果是，每个 Unicorn 可以处理的并发用户范围是多少，具体取决于系统资源（假设低端为 1 GB，高端为您认为合适的任何值）？
并发用户会话与并发连接之间存在差异。会话是指在线用户，他们每次交互时都会发出一个请求（连接）。
它不会。Unicorn在启动时会分叉成一定数量的工作进程。
而且，我认为我们看到，每个工作进程运行 10 个线程。