Ruby on Rails 应用程序的 Heroku 配置

Question

我已经为 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

Answer 1

您的 WEB_CONCURRENCY 对于您的 Standard-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 并发性（这可能意味着您还需要增加 dyno 的数量以进行补偿）或者您需要使用更大的 dyno。

您已经拥有MALLOC_ARENA_MAX=2，但不确定您是否在使用jemalloc。你可能想try that too。

当然，您的应用中可能还存在其他内存问题 - 请查看一些提示 here。我还建议添加一个像 AppSignal 这样的监控工具，因为它能够为每个事务提供 tracking memory allocations。

对于缓解 H12：

1. 确保您已经安装了类似rack-timeout gem 的东西，它可以确保在dyno 级别丢弃长时间运行的请求，从而避免H12 错误（您会得到Rack::TimeoutError 异常）。将超时时间设置为 15 秒，这样 H12 超时时间将远低于 30 秒。
2. 调查您的缓慢事务。监控工具是这里的关键，即New Relic（从价格最低的付费计划开始 - 免费计划不允许交易跟踪）。这是他们在how to trace transactions 上的博客文章
3. 发现问题后 - 解决问题！

• 如果瓶颈是外部的：
  • 检查外部 API 限制和限制
  • 添加超时并让应用适应缓慢的外部响应
• 如果瓶颈是由数据库引起的：
  • optimize slow queries
  • check cache hit rates
  • 检查等待连接数和db locks -> 如果等待连接数在 X 分钟内始终高于 0，则表明您有一些需要调查的长锁。使用Librato 最容易跟踪等待连接（免费计划应该可以）
• 如果瓶颈是其他应用程序代码：
  • 添加更多自定义工具以获得更多见解，即New Relic instructions
  • 解决应用代码问题

我想强调监控工具在帮助诊断问题和确定最佳资源使用方面的重要性。如果没有适当的监控工具，几乎不可能找出正确的并发配置、正确的大小和要运行的 dyno 数量。希望您的etc add-ons 已经涵盖了一些未列出的内容，但如果您没有，我将总结我的建议并提一些其他提示：

• 要获取更多指标信息，请确保您拥有enabled log-runtime-metrics
• 同时启用Ruby language metrics
• 添加一个可以跟踪 Ruby 内存分配的监控工具，例如 AppSignal。 Scout APM 也可以这样做，但我认为他们能够做到这一点的计划更昂贵（需要 Scout Insights 功能）
• 添加最低付费版本的New Relic。这是我用于交易跟踪的首选工具。如果您不想为其他工具付费，AppSignal 也可以做到这一点，但我发现使用 New Relic 更容易。
• 添加Librato。它提供了一些开箱即用的出色图表，包括在自己的仪表板中的一组 Postgres 图表。
• 在您的监控应用程序中设置警报，以警告您响应时间等信息，以便您查看它们！
• 当然，首先在暂存阶段进行所有更改并load test 他们在尝试生产之前查看更改的影响！

更新：我还刚刚注意到您说您使用的是 Standard-0 Postgres，这意味着它有一个 120 connection limit。因此，如果您最终降低了WEB_CONCURRENCY 并增加了测功机的数量，请注意您与该数据库的总连接数。除了存在限制这一事实之外，更多的连接也意味着更多的数据库开销，因此如果您接近连接限制，您更有可能看到数据库性能受到影响。您可能想要升级到具有更高连接限制的另一个计划或使用pgbouncer as your connection pooler 来避免连接限制。