gpt4 book ai didi

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

转载 作者:可可西里 更新时间:2023-11-01 06:30:56 24 4
gpt4 key购买 nike

我们的 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配置、数据库连接等)

提前谢谢你。

更新:安装 gem rack_timer 记录每个中间件花费的时间后,我意识到当挂起时我们的请求一直停留在 ActiveRecord::QueryCache 上,上面有大量时间:

Rack Timer (incoming) -- ActiveRecord::QueryCache: 925626.7731189728 ms

我暂时删除了这个中间件,它似乎恢复了正常。但是,我知道这个中间件的目的是提高性能,所以删除它只是一个临时解决方案。请帮助我找出导致此问题的可能原因。

仅供引用,我们正在使用带有适配器 mysql2 (0.3.13) 的 mysql (5.1.67)

最佳答案

这可能是由于查询缓存变得太大而导致 RAM 不足的症状。我们在 Heroku 上运行的一个应用程序中看到了这一点。默认查询缓存设置为 1000。降低限制可以减轻我们的 RAM 使用量,而不会明显降低性能:

数据库.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

关于mysql - 一段时间后服务器挂起所有请求,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26303764/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com