服务器在一段时间后挂起所有请求

Question

我们的Rails 4.0应用程序(Ruby 2.1.2)使用Puma 2.9.0在Nginx上运行.

我最近注意到,对我们的应用程序的所有请求都会在一段时间后停止(通常为1或2天).

检查设置为debugmode的日志时,我注意到以下日志堆栈:

[2014-10-11T00:02:31.727382 #23458]  INFO -- : Started GET "/" for ...

它确实意味着请求实际上访问了Rails应用程序,但不知何故它没有继续,而通常它会是:

I, [2014-10-11T00:02:31.727382 #23458]  INFO -- : Started GET "/" for ....
I, [2014-10-11T00:02:31.729393 #23458]  INFO -- : Processing by HomeController#index as HTML

我的puma配置如下:

threads 16,32
workers 4

我们的应用程序仅用于现在的内部使用,因此RPM非常低,并且所有请求都不会超过2秒.

可能导致此问题的原因是什么？(puma配置,数据库连接等)

先感谢您.

更新:在安装gem rack_timer以记录在每个中间件上花费的时间之后,我意识到我们的请求在发生挂起时一直停留在ActiveRecord :: QueryCache上,并且有大量时间:

Rack Timer (incoming) -- ActiveRecord::QueryCache: 925626.7731189728 ms

我暂时删除了这个中间件,它似乎恢复正常.但是,我理解这个中间件的目的是提高性能,因此删除它只是一个临时解决方案.请帮我找出这个问题的可能原因.

仅供参考,我们使用mysql(5.1.67)和适配器mysql2(0.3.13)

Answer 1

这可能是由于查询缓存变得太大而导致 RAM 不足的症状。我们在 Heroku 上运行的一款应用程序中看到了这一点。默认查询缓存设置为 1000。降低限制可以减轻我们的 RAM 使用量，而不会出现明显的性能下降：

数据库.yml：

default: &default
  adapter: postgresql
  pool: <%= ENV["DB_POOL"] || ENV['MAX_THREADS'] || 5 %>
  timeout: 5000
  port: 5432
  host: localhost
  statement_limit: <%= ENV["DB_STATEMENT_LIMIT"] || 200 %>

然而，搜索“activerecord querycache Slow”会返回其他原因，例如可能是过时的 Ruby 或 Puma 版本或机架超时： /sf/answers/3091110711/

或者 read_timeout 的值可能太大：https ://stackoverflow.com/a/30526430/126636