ruby-on-rails - Ruby on Rails 应用程序的 Heroku 配置
问题描述
我已经为 Heroku 的 Ruby on Rails 应用程序建立了一个客户,多年来,无论我们在额外资源上花费了多少钱,他们的应用程序都无法正常运行,因此遇到了很多麻烦,发现他们的文档非常混乱。我一直无法理解他们的具体术语和文档。我们不断收到“H12”错误和“R14”错误等。内存使用量和测功机负载不断飙升。然而,这是一家没有大量流量的中小型企业。想知道是否有任何了解 Heroku 来龙去脉的人可以查看此配置并告诉我它是否有意义:
DB_POOL: 10
MALLOC_ARENA_MAX: 2
RAILS_MAX_THREADS: 5
WEB_CONCURRENCY: 4
Ruby 2.7
Rails 6.0
Puma
8 2x web dynos
5 1x worker dynos
$50 Postgres standard 0 database
$15 Memcachier
$10 Rediscloud
...etc addons
解决方案
你WEB_CONCURRENCY
的标准 2x 测功机太高了。推荐的默认值为 2:https ://devcenter.heroku.com/articles/deploying-rails-applications-with-the-puma-web-server#recommended-default-puma-process-and-thread-configuration
这可能会导致您的 R14 错误,因为更高的 Web 并发性意味着更多的内存使用。因此,您需要降低 Web 并发性(这可能意味着您还需要增加 dynos 的数量来补偿)或者您需要使用更大的 dynos。
您已经拥有MALLOC_ARENA_MAX=2
但不确定是否正在使用jemalloc
. 您可能也想尝试一下。
当然,您的应用程序中可能还存在其他内存问题 - 请在此处查看一些提示。我还建议添加一个像AppSignal这样的监控工具,因为它能够跟踪每个事务的内存分配。
对于缓解 H12:
- 确保您已经安装了类似
rack-timeout
gem 的东西,它可以确保在 dyno 级别丢弃长时间运行的请求,从而避免 H12 错误(您会得到一个Rack::TimeoutError
异常)。将超时设置为 15 秒,使其远低于 H12 超时的 30 秒。 - 调查您的缓慢交易。监控工具是这里的关键,即New Relic(从价格最低的付费计划开始 - 免费计划不允许交易跟踪)。这是他们关于如何跟踪交易的博客文章
- 当您发现问题时 - 修复它!
- 如果瓶颈是外部的:
- 检查外部 API 限制和限制
- 添加超时并使应用程序适应缓慢的外部响应
- 如果瓶颈是由于数据库引起的:
- 如果瓶颈是其他应用程序代码:
- 添加更多自定义工具以获得更多见解,即New Relic 指令
- 解决应用程序代码问题
我想强调监控工具在帮助诊断问题和帮助确定最佳资源使用方面的重要性。如果没有适当的监控工具,几乎不可能进行诸如找出正确的并发配置、正确的大小和要运行的测功机数量之类的事情。希望您已经有一些etc add-ons
未列出的内容,但如果您没有,我将总结我的建议并提及其他一些提示:
- 要获取更多指标信息,请确保您已启用
log-runtime-metrics
- 同时启用Ruby 语言指标
- 添加一个可以跟踪 Ruby 内存分配的监控工具,例如AppSignal。Scout APM也可以做到这一点,但我认为他们能够做到这一点的计划更昂贵(需要 Scout Insights 功能)
- 添加最低付费版本的New Relic。这是我进行交易跟踪的首选工具。如果您不想为其他工具付费,AppSignal 也可以做到这一点,但我发现使用 New Relic 更容易。
- 添加天秤座。它提供了一些开箱即用的出色图表,包括自己仪表板中的一组 Postgres 图表。
- 在您的监控应用程序中设置警报,以警告您响应时间等信息,以便您查看它们!
- 当然,首先在暂存中进行所有更改并对其进行负载测试以查看更改的影响,然后再尝试生产!
更新:我也刚刚注意到您说您使用的是 Standard-0 Postgres,这意味着它有120 个连接限制。因此,如果您最终降低WEB_CONCURRENCY
并增加了测功机的数量,请注意您与该数据库的总连接数。除了存在限制这一事实之外,更多的连接也意味着更多的数据库开销,因此如果您接近连接限制,您更有可能看到数据库性能受到影响。您可能希望升级到具有更高连接限制的另一个计划或pgbouncer
用作连接池以避免连接限制。