Discourse 因 PSQL 连接问题崩溃

我们的论坛一直出现这个消息(大约每 3-4 小时一次)。我们有 16 核 CPU 和 32GB 内存。我不认为资源是问题所在。

糟糕
为这个讨论论坛提供支持的软件遇到了意外问题。我们对造成的不便深表歉意。

有关错误的详细信息已记录,并生成了自动通知。我们会对其进行检查。

无需进一步操作。但是,如果错误状况持续存在,您可以通过在该站点的反馈类别中发布讨论主题来提供更多详细信息,包括重现错误的步骤。

生产日志显示


app/models/user_auth_token.rb:125:in `lookup'
lib/auth/default_current_user_provider.rb:131:in `current_user'
lib/current_user.rb:35:in `current_user'
app/controllers/application_controller.rb:1047:in `rate_limit_crawlers'
lib/middleware/omniauth_bypass_middleware.rb:64:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
lib/middleware/anonymous_cache.rb:393:in `call'
lib/middleware/csp_script_nonce_injector.rb:12:in `call'
config/initializers/008-rack-cors.rb:14:in `call'
config/initializers/100-silence_logger.rb:27:in `call'
lib/middleware/enforce_hostname.rb:24:in `call'
lib/middleware/request_tracker.rb:236:in `call'
Message Bus 中出现意外错误:ActiveRecord::ConnectionNotEstablished:连接到服务器“172.17.0.2”,端口 5432 失败:致命错误:剩余的连接槽已保留给非复制超级用户连接

Message Bus 中出现意外错误:ActiveRecord::ConnectionNotEstablished:连接到服务器“172.17.0.2”,端口 5432 失败:致命错误:剩余的连接槽已保留给非复制超级用户连接

Message Bus 中出现意外错误:ActiveRecord::ConnectionNotEstablished:连接到服务器“172.17.0.2”,端口 5432 失败:致命错误:剩余的连接槽已保留给非复制超级用户连接

Message Bus 中出现意外错误:ActiveRecord::ConnectionNotEstablished:连接到服务器“172.17.0.2”,端口 5432 失败:致命错误:剩余的连接槽已保留给非复制超级用户连接

我们在以下位置设置了配置:

UNICORN_WORKERS: 32
UNICORN_SIDEKIQS: 2

以及 psql

db_shared_buffers: "4096MB"

请告诉我还可以做些什么来改进配置并确保服务器不会崩溃。

我建议为 postgres (db_shared_buffers) 分配至少 16GB,如果不是 20GB 的内存。

但是你需要增加数据库连接数。我不记得具体该怎么做了。

我认为你需要更改 /etc/postgresql/postgresql.conf(在运行 postgres 的容器内)中的 max_connections 参数。

1 个赞

我也这么认为。 :+1:

你确定吗?这似乎很高。请参阅 PostgreSQL: Documentation: 13: 19.4. Resource Consumption

如果您有一个拥有 1GB 或更多内存的专用数据库服务器,shared_buffers 的一个合理起始值是您系统内存的 25%。在某些工作负载下,即使更大的 shared_buffers 设置也有效,但由于 PostgreSQL 也依赖于操作系统缓存,因此分配给 shared_buffers 的内存超过 RAM 的 40% 可能不如分配较少内存效果好。

而且这不是一个专用的数据库服务器,上面还有 32 个 unicorn 进程。

在这类事情上我总是听你的,而且我以为我是在引用你过去给出的建议,所以,,我不确定。 :rofl:

很明显问题在于连接,将 RAM 增加到 32GB 的 25% 可能在一般情况下有所帮助,但并不是错误的根源。

编辑:

哈!这正是我记得的,只是看起来我将超过 50%……

1 个赞

我承认有“罪”

但那已经是过去式了…… :wink:

:100:

2 个赞

为什么?这些是导致您耗尽连接槽的原因。

1 个赞

我记得在哪里看到过,UNICORN WORKER 应该是 2 * CPU。所以我算了一下是 32。我应该缩小规模吗?

我们尝试通过运行 ALTER ROLE discourse SET statement_timeout = '30000'; 来更改 PSQL 的超时设置。这个查询每隔几个小时就会被阻塞一次。


不确定您或其他人是否知道发生了什么?

不,请删除此项,让默认值生效。这是过早优化的典型案例。

2 个赞

是的,你碰了你不该碰的东西 :wink:

1 个赞

9 个帖子被拆分到一个新主题:建议工作线程数:核心数 × 2?