ruby-on-rails – Rails查询执行会导致数据库尖峰

前端之家收集整理的这篇文章主要介绍了ruby-on-rails – Rails查询执行会导致数据库尖峰前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我的Rails应用程序有一个问题,其中一些随机查询需要大约5秒钟或更长时间才能完成.大多数时候,查询非常简单(select * from x where id =?),字段甚至是索引.

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

>美洲狮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秒..秒.
这是一个在行动中的图片

我试过的事情

>增加线程池,以确保美洲豹工作线程有足够的连接对象.
>将’reaping_frequency’设置为10秒,以确保没有使用死连接.
>增加美洲狮工人/线程

我在应用程序中注意到这一点,因为有些页面需要很长时间才能加载(我有一个函数调用大约需要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

解决方法

我会提出几件事情 – 两种可能的解决方案,一种测试/复制方法,以及一个更深入的指标的建议.

1)可能的快速解决方案:分离1分钟作业,使其无阻塞.看看问题是否解决了.尝试使用Redis Sidekiq,这是很简单的起床和运行(或类似的东西).

2)第二个可能的解决方案:寻找任何完整的表锁或独占行锁定Postgres – 看看你是否做了完整的表锁,如果是,找到违规的声明,并消除它.

3)测试/复制:对于测试,看看是否可以在生产之外复制此问题.我建议将jmeter作为一个非常有用的工具来模拟不同类型的大量请求和请求,并且看看是否可以在受控/分段上下文中进行修改.一致的复制是解决这类问题的关键.请在生产服务器日志的时候发生问题,以生成您希望能够帮助重现此问题的jmeter测试请求.

如果您可以找出一种复制方式,那么您可以开始调整模拟,以查看是否删除增加/减少各种请求会消除问题或以某种方式更改问题.

4)分析:安装NewRelic或类似的分析宝石,以便深入了解该请求的进展情况.您真的想要看到Postgres中的请求是否被真正阻止(通过独占行/表)锁定阻止您的查询),或者您是否在Puma执行队列中由慢速运行的查询进行备份,或者Ruby内部的某个地方有不幸的等待状态.

您还没有足够的信息来解决这个问题,所以您真的想通过收集数据,以及发生的事情的假设开始探索解决方案.

我对这种问题的总体策略是(按顺序):

>尝试一些快速/简单/安全的修复(在盲人),看看是否有任何解决/改变.>尝试在非生产环境中复制(真的,真的试着让这个工作).>仪器系统收集数据,看看你可以了解有关问题和任何相关的内容.

原文链接:https://www.f2er.com/ruby/265869.html

猜你在找的Ruby相关文章