请求卡在 PG::Connection#async_exec [英] Requests get stuck in PG::Connection#async_exec
问题描述
我正在尝试使 rails 应用程序在 passenger 下工作，但到目前为止还没有运气.它使用 sequel 连接到 postgresql.随机请求需要太多时间才能完成.我能够找到应用程序花费时间的地方:
I'm trying to make a rails application work under passenger with no luck so far. It uses sequel to connect to postgresql. Requests randomly take too much time to complete. I was able to find where the app is spending its time:
%self total self wait child calls name
99.92 65.713 65.713 0.000 0.000 5 PG::Connection#async_exec
0.00 0.002 0.002 0.000 0.000 264 Set#delete
...
据说，webrick 不会发生这种情况，我将尝试在 unicorn 下运行它.
Supposedly, it doesn't happen with webrick, and I'm going to try and run it under unicorn.
我正在使用 passenger-5.0.30、ruby-2.3.0、postgresql-9.4、pg-0.19.0，rails-5.0.0.1.unicorn-5.1.0 也是如此.该应用程序在 lxc 容器中运行.主机和来宾操作系统是 ubuntu/xenial.
I'm using passenger-5.0.30, ruby-2.3.0, postgresql-9.4, pg-0.19.0, rails-5.0.0.1. The same goes for unicorn-5.1.0. The app is running in lxc container. Host and guest OSs are ubuntu/xenial.
推荐答案
问题在我们开始重新建立与数据库的连接后得到解决.我们在项目中使用了 sequel，只有当使用 ActiveRecord 时，Passenger 才会自己处理问题.
The issue was resolved after we started reestablishing connections to database. We were using sequel on the project, and Passenger handles the issue itself only when ActiveRecord is used.
为了扩展它，默认情况下，Passenger 为 ruby 应用程序使用智能生成.它首先产生预加载器进程，该进程加载框架和所有库.之后，当需要时，预加载器进程产生工作进程，处理请求.生成工作进程时，所有文件描述符都继承自预加载进程.因此，如果您不重新建立与数据库的连接，则所有工作进程共享一个，由预加载器建立.这导致了各种奇怪的行为.比如请求时间太长.
To expand on it, by default Passenger uses smart spawning for ruby apps. It first spawns preloader process, which loads framework and all the libraries. After that preloader process spawns worker processes when the need arises, which handle the requests. When spawning worker processes, all file descriptors are inherited from preloader process. So if you don't reestablish connection to database, all worker process share one, established by preloader. Which leads to all sorts of weird behavior. Like requests taking too long.
在此之前，我们还将处理 WebSocket 连接转移到一个单独的进程.但是不确定它是否导致了这个问题.
Before that, we also moved handling WebSocket connections to a separate process. Not sure if it contributed to the issue however.
更多相关信息:
如果使用带代码预加载的分叉 Web 服务器断开连接
无意的文件描述符共享
在同一主机和端口上运行 Action Cable 服务器，在子 URI 下
这篇关于请求卡在 PG::Connection#async_exec的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
