Question

长期以来，生产中一直存在着棘手的问题，我们不知道问题的根源。有时可以在localhost上重现它，Heroku Enterprise支持对此一无所知。

在生产数据库中，我们当前具有以下设置：

a SELECT * FROM pg_stat_activity GROUP BY client_addr并计算每个实例的连接数表明，在我们的高峰期，为一个乘客流程打开了1个以上的PSQL连接。

假设：

以下是SELECT * FROM pg_stat_activity;的屏幕截图：

在屏幕截图中，我们可以看到有 45个psql连接来自运行乘客的同一个dyno。如果我们遵循以前的逻辑，则每个“乘客”进程的连接数不应超过1，因此应为25。

日志看起来并不异常，没有提到dyno崩溃/进程崩溃。

以下是同一次dyno的乘客状态的屏幕截图（不同的时间，只是为了证明一个dyno所创建的流程不超过25个）：

最后，我们从Heroku支持小组获得的回应之一（惊人的支持顺便说一句）

我还看到过以前的报道，《乘客使用比预期更多的连接》，但不幸的是，大多数都由于复制困难而关闭。

在“乘客”文档中，解释了“乘客”自行处理ActiveRecord连接。

任何潜在客户均表示赞赏。谢谢！

各种信息：

如果您需要更多信息，请在评论中让我知道，我将很乐意更新此帖子。

最后一件事：我们使用ActionCable。我读过某个地方，乘客在奇怪地处理套接字连接（打开一个有点隐藏的过程以保持连接有效）。这是我们的领先者之一，但到目前为止，在本地主机上复制它并不算运气。如果有人能确认乘客如何处理ActionCable连接，将不胜感激。

更新1（01/10/2018）：

实验：

按以下说明禁用NewRelic自动解释功能：https://devcenter.heroku.com/articles/forked-pg-connections#disabling-new-relic-explain
在本地运行一个最小和最大池大小设置为3的乘客服务器（更多会使我的计算机烧毁），然后使用各种信号（SIGKILL，SIGTERM）终止进程以尝试查看连接是否正确关闭。他们是。

Answer 1

我们终于设法解决了关于旅客的问题。实际上，我们已经有很长时间了。

修复

如果您使用ActionCable，并且默认电缆路由为/cable，请从以下位置更改Procfile：

web: bundle exec passenger start -p $PORT --max-pool-size $PASSENGER_MAX_POOL_SIZE

到

web: bundle exec passenger start -p $PORT --max-pool-size $PASSENGER_MAX_POOL_SIZE --unlimited-concurrency-path /cable

说明

在进行更改之前，每个套接字连接（ActionCable）在Passenger中将执行一个单独的过程。但是，Socket实际上不应该占用整个过程。一个进程可以处理许多许多开放的套接字连接。（对于一些知名品牌，许多人同时拥有超过一万个）。幸运的是，我们的套接字连接要少得多，但是仍然如此。

更改后，我们基本上告诉乘客不要用整个过程来处理一个套接字连接，而是要用一个完整的过程来处理所有套接字连接。

文档

某些指标，修复3周后