我有一个使用NGINX和Puma托管的rails应用程序。每10个小时左右,该应用程序将无法使用。每当用户尝试连接时,都会显示以下错误消息:
Error during failsafe response: could not obtain a database connection within 5.000 seconds (waited 5.000 seconds)
这一直持续到应用程序重新启动。
我已经读过这是因为数据库连接池已满,因此必须在rails应用程序中创建线程,这些线程在完成时不会关闭与数据库的连接。 据我所知,应用程序代码中只有一个位置使用线程:一个块使用Ruby Timeout模块,但这不访问数据库。
遵循本指南 https://devcenter.heroku.com/articles/concurrency-and-database-connections(我实际上并没有使用Heroku) 我已将数据库连接池的大小设置为5,使用以下配置文件:
#config/initializers/database_connection.rb
Rails.application.config.after_initialize do
ActiveRecord::Base.connection_pool.disconnect!
ActiveSupport.on_load(:active_record) do
config = ActiveRecord::Base.configurations[Rails.env] ||
Rails.application.config.database_configuration[Rails.env]
config['reaping_frequency'] = ENV['DB_REAP_FREQ'] || 10 # seconds
config['pool'] = ENV['MAX_THREADS'] || 5
ActiveRecord::Base.establish_connection(config)
end
端
该站点使用Rails 4.0.0托管。我已经读过这可能实际上是一个Rails 4.0.0问题,并且这在以后的版本中得到修复,但我不确定。 ConnectionTimeoutError on Heroku with Postgres
rails应用程序正在生产环境中运行。如果需要,我可以提供有关我的Puma,NGINX配置的更多信息。
答案 0 :(得分:2)
故障安全响应试图分配数据库连接的事实可能是冒烟的枪。它可能有助于您描述故障安全响应中发生的情况。当原始请求触发异常时,可能会触发故障安全响应。在ConnectionManager调用clear_active_connections之后调用调用故障安全响应的rails show_exception例程!对于当前请求(因异常而失败),这意味着在故障安全响应失败后,rails不会自动释放数据库连接。这意味着故障安全响应处理程序负责清理自己的数据库连接。我不确定故障安全响应处理程序是否尝试连接到数据库,但如果这是所需的行为,那么您可能需要调用clear_active_connections!显式位于故障安全处理程序的末尾(在确保块中)。
我一直在调查我自己的应用中的类似问题,并发现这是一个有用的指南,指导连接的工作方式:https://bibwild.wordpress.com/2014/07/17/activerecord-concurrency-in-rails4-avoid-leaked-connections/。虽然这里引用的代码可能需要一些调整,但在那里有一个很好的概述,如何检测何时创建隐式数据库连接。
答案 1 :(得分:0)
我不认为它是导致4.0.0问题。
正如ruby timeout module documentation中提到的,它产生了一个新线程。我认为它有可能产生长时间运行的线程,以保持数据库连接的实时性。要检查正在运行的线程,您可以使用Thread.list
方法。另外请记住,你的游泳池大小必须> puma线程,而不是puma线程倍增puma worker。