Question

我们的Rails 4.0应用程序（Ruby 2.1.2）使用Puma 2.9.0在Nginx上运行。

我最近注意到，我们的应用程序的所有请求都会在一段时间后停止（通常为1或2天）。

检查设置为debug模式的日志时，我注意到以下日志堆栈：

[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 config，数据库连接等）

提前谢谢。

更新：安装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使用量，而不会出现明显的性能下降：

database.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的过期版本或机架超时：https://stackoverflow.com/a/44158724/126636

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

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

1 个答案:

database.yml中：