Question

我的Rails应用程序出现问题，其中一些随机查询需要大约5秒或更长时间才能完成。大多数情况下，查询非常简单（select * from x where id = ?），字段甚至也被编入索引。

以下是有关设置的更多信息：

Puma 3.5.0背后的逆转nginx代理
- 4名工人，每人最少4个，最多8个。
Ruby v2.2.3，Rails v4.2.4
PostgreSQL 9.4数据库
- 线程池设置为最多60个连接
用于监控的Appsignal
8GB RAM，4个CPU，SSD。

在查看Appsignal中的查询性能时，我发现了这一点。我注意到大多数查询在几毫秒内完成，然后时不时地，仍然在同一个请求中，有多个查询需要5秒多才能完成。奇怪的是它总是需要5秒......。这是实际情况的图片：

我尝试的事情：

增加线程池以确保puma工作线程有足够的连接对象。
设置＆＃39; reaping_frequency＆＃39;到10s，以确保没有使用死连接。
增加美洲狮工人/线程

我在应用程序中注意到这一点，因为有些页面需要很长时间才能加载（我有一个函数调用需要大约1分钟才能完成）并且不知何故这会阻止新的请求。这对我来说很奇怪，因为有4个工作程序，每个工作程序有8个线程= 32个线程可以处理其他请求。

我在上面的图片中对查询进行了解释，这是输出：

Limit  (cost=0.28..8.30 rows=1 width=150)
  ->  Index Scan using index_addresses_on_addressable_id_and_addressable_type on addresses  (cost=0.28..8.30 rows=1 width=150)
        Index Cond: ((addressable_id = 1) AND ((addressable_type)::text = 'University'::text))
        Filter: (deleted_at IS NULL)
Total query runtime: 13 ms

这是地址表的架构：

# Table name: addresses
#
#  id               :integer          not null, primary key
#  street           :string
#  zip_code         :string
#  city             :string
#  country          :string
#  addressable_id   :integer
#  addressable_type :string
#  created_at       :datetime         not null
#  updated_at       :datetime         not null
#  street_number    :string
#  latitude         :float
#  longitude        :float
#  mobile           :string
#  phone            :string
#  email            :string
#  deleted_at       :datetime
#  name             :string`

这是我的Puma配置文件：

#!/usr/bin/env puma

directory '/home/deployer/apps/qeystate/current'
rackup "/home/deployer/apps/qeystate/current/config.ru"
environment 'staging'   
pidfile "/home/deployer/apps/qeystate/shared/tmp/pids/puma.pid"
state_path "/home/deployer/apps/qeystate/shared/tmp/pids/puma.state"
stdout_redirect '/home/deployer/apps/qeystate/shared/log/puma_access.log', '/home/deployer/apps/qeystate/shared/log/puma_error.log', true
threads 4,8
bind 'unix:///home/deployer/apps/qeystate/shared/tmp/sockets/puma.sock'
workers 4
preload_app!
prune_bundler

on_worker_boot do
  ActiveSupport.on_load(:active_record) do
    ActiveRecord::Base.establish_connection
  end
end

before_fork do
  ActiveRecord::Base.connection_pool.disconnect!
end

Answer 1

我会建议一些事情 - 两种可能的解决方案，一种测试/再现方法，以及一种更深层次指标的建议。

1）可能的快速解决方案：剥离1分钟的工作，使其无阻塞。查看问题是否可以解决。尝试使用Redis + Sidekiq，它非常简单，可以起床和运行（或类似的东西）。

2）第二种可能的解决方案：查找对Postgres进行的任何完整表锁或独占行锁 - 查看您是否进行全表锁，如果是，请查找有问题的语句并将其消除。

3）测试/复制：对于测试，看看是否可以在生产之外复制此问题。我建议使用jmeter作为一个非常有用的工具来模拟不同类型的许多请求和请求，看看你是否可以在受控/暂存环境中重现它。一致的复制是解决此类问题的关键。在生成问题时，请参阅生产服务器日志，以生成有希望帮助重现问题的jmeter测试请求。

如果你能找到一种方法来复制它，那么你可以开始调整模拟，看看删除或增加/减少各种请求是否可以消除问题或以某种方式改变问题..

4）分析：安装NewRelic或类似的分析gem，以便更深入地了解该请求进入时的情况。您真的想要了解Postgres中的请求是否真正被阻止（通过独家阻止你的查询的行/表锁）或者是否由Puma执行队列中的慢速运行查询备份，或者在Ruby内部某处以某种方式存在不幸的等待状态。

您还没有足够的信息来解决这个问题，因此您真的希望通过收集数据以及对正在发生的事情的假设来开始探索解决方案。

我对此类问题的一般策略是（按此顺序）：

尝试一些快速/简单/安全修复（在盲人中）并查看是否有任何解决/更改。
尝试在非生产环境中复制（真的，真的尝试使这项工作）。
检测系统以收集数据，以了解您可以了解的问题以及相关的任何内容。

Rails查询执行导致数据库峰值

1 个答案: