Question

我有一个使用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应用程序代码中使用Timeout模块可能是导致此问题的原因吗？
这可能是Rails 4.0.0问题，而不是我的应用程序的问题吗？

rails应用程序正在生产环境中运行。如果需要，我可以提供有关我的Puma，NGINX配置的更多信息。

Answer 1

故障安全响应试图分配数据库连接的事实可能是冒烟的枪。它可能有助于您描述故障安全响应中发生的情况。当原始请求触发异常时，可能会触发故障安全响应。在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/。虽然这里引用的代码可能需要一些调整，但在那里有一个很好的概述，如何检测何时创建隐式数据库连接。

Answer 2

我不认为它是导致4.0.0问题。

正如ruby timeout module documentation中提到的，它产生了一个新线程。我认为它有可能产生长时间运行的线程，以保持数据库连接的实时性。要检查正在运行的线程，您可以使用Thread.list方法。另外请记住，你的游泳池大小必须> puma线程，而不是puma线程倍增puma worker。

Rails 4数据库连接池错误

2 个答案: