我在 Heroku 上有一个应用程序,在 Puma 上运行:
workers 2
threads_count 3
pool 5
看起来有些请求被困在中间件中,这使得应用程序非常慢(非常!)。
我看到其他人讨论过这个问题,但到目前为止还没有解决方案。
如果您有任何提示,请告诉我。
!
!
我为 Heroku 支持工作,Middleware/Rack/ActiveRecord::QueryCache#call
是 New Relic 经常报告的一个问题。不幸的是,这通常是转移注意力的事情,因为每次问题的根源都在别处。
QueryCache
是 Rails 首先尝试检查连接是否可用的地方,因此连接的任何问题都会在此处显示为请求“卡住”等待。这并不意味着数据库服务器必然失去连接(如果您有 Postgres 的 Librato 图表,它们会显示这一点)。这可能意味着某些原因导致某些数据库连接进入错误状态,并且新的连接请求正在等待。这可能发生在旧版本的 Puma 中,其中使用了多个线程并且reaping_frequency
设置 - 如果某些连接进入不良状态而其他连接被收获,这将导致问题。
一些高层建议如下:
- 升级 Ruby 和 Puma
- 如果使用
rack-timeout
gem,也升级一下
这些升级通常会有所帮助。如果没有,还可以考虑其他选项,例如从线程切换到基于工作进程的进程或使用 Postgres 连接池(例如 PgBouncer)。我们在此处提供了有关配置并发 Web 服务器以与 Postgres 一起使用的更多建议:https://devcenter.heroku.com/articles/concurrency-and-database-connections https://devcenter.heroku.com/articles/concurrency-and-database-connections
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)