以下是有关设置的更多信息:
>美洲狮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内部的某个地方有不幸的等待状态.
您还没有足够的信息来解决这个问题,所以您真的想通过收集数据,以及发生的事情的假设开始探索解决方案.
我对这种问题的总体策略是(按顺序):
>尝试一些快速/简单/安全的修复(在盲人),看看是否有任何解决/改变.>尝试在非生产环境中复制(真的,真的试着让这个工作).>仪器系统收集数据,看看你可以了解有关问题和任何相关的内容.