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

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工作线程具有足够的连接对象.
• 将'reaping_frequency'设置为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 内部的某个地方以某种方式存在不幸的等待状态。

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

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

• 尝试一些快速/简单/安全的修复（盲目地），看看是否有任何问题得到解决/改变。
• 尝试在非生产环境中进行复制（真的，真的尝试让这项工作发挥作用）。
• 使用系统来收集数据，看看您可以了解有关问题和相关的信息。