ruby-on-rails - Heroku:一个简单的 Rails 应用程序定期停机 15 分钟

Question

我是 Rails 的新手，刚刚将我的第一个应用程序部署到 Heroku(在免费层)。我设置了 New Relic 的免费试用版，并将可用性监控设置为每 1 分钟 ping 我的/register/URL。我正在运行 Rails 3.2.13 和 Ruby 1.9.3。

我的应用基本上没有用户，也没有请求(每分钟 2 个请求，大部分来自 NewRelic)。我没有后台服务或外部依赖项。数据模型很简单，所有查询都不会超过 100 毫秒。

我每隔几个小时就会遇到一次持续整整 15 分钟的完全中断。

由于 Heroku 只保留 1500 行日志，所以我没有每个事件的数据，但这是第二个 blip 的日志(我的图表是 -0400，Heroku 是 UTC)。

完整日志: https://gist.github.com/jbinto/5495226/raw/ba61ec16d9655287466cfbb9328f59c0171b2df7/heroku.log

总结

• 00:56:21 到 01:00:21:它像往常一样每分钟发出 1 个请求。
• 01:01:55:最后一个请求似乎没有得到满足。
• 01:02:21 到 01:17:21: 54 个 H12(请求超时)错误。
• 01:17:25: PG::Error(SSL SYSCALL 错误:检测到 EOF)(另外:我注意到 Heroku 的日志语句乱序，很奇怪。)

这个 PG::Error 是我问题的原因，还是仅仅是一个症状？一些谷歌搜索显示了关于 Postgres 在入门层超时的讨论，以及一些不使用生产层的警告: https://groups.google.com/forum/?fromgroups=#!topic/heroku/a6iviwAFgdY

更多 StackOverflow: Postgres + Heroku SSL SYSCALL error

还有一张关于自动重新连接的 Rails 票据: https://github.com/rails/rails/issues/9421

这看起来是一个很好的线索，但似乎没有人解决过这个问题。似乎 Heroku 的 Postgres 存在一些问题，而 Rails<4 并没有从中恢复得很好。

• 01:17:26 到 01:17:27: 58 个 GET 请求被“服务”(我想这些是排队的请求？由于 30 秒的超时，客户端早已消失。为什么这些请求仍然通过？)
• 01:17:51:一切恢复正常。

有什么想法吗？我将开一张 Heroku 支持票，但不确定我是否能以免费用户的身份获得任何帮助。

Answer 1

答案在这里:


T01:02:21.144033+00:00 heroku[router]: at=error code=H12 desc="请求超时"method=HEAD path=/register host=www.puckpicks.ca fwd="50.18.57.7"dyno=web .1 连接=1ms 服务=30000ms 状态=503 字节=0


您通常会看到这种模式，其中一个长时间运行的操作开始占用所有进一步请求的队列。

Heroku 路由器将在 30 秒后丢弃长时间运行的请求，但它后面的 dyno 将继续处理请求直到完成。但是，路由器并不知道它，所以它会向那个繁忙的 dyno 发送新请求。这种影响趋于复合，您会在 New Relic 中看到排队，最终甚至对于不相关的 URL(如静态 Assets )也会出现 H12 错误。

你可能想要安装类似 rack-timeout 的东西，这将确保长时间运行的请求也在 dyno 级别被丢弃。具体来说， rack-timeout 在发生这种情况时会引发 TimeoutError 。 https://github.com/kch/rack-timeout

有了它，复合效应就不太可能发生，但仍然需要解决长时间运行的操作。 New Relic 是一个很好的工具，可以提供对应用程序的可见性，以识别长时间运行的操作。然后你可以优化它们并确保它们能够在合理的时间内完成，我建议将所有请求保持在 500 毫秒以下。如果他们正在执行任何固有的长任务，您应该尝试将这些任务卸载给后台工作人员。

如果你有更高流量的生产应用我也建议你使用Unicorn如果您还没有，那么您的应用程序可以处理并发请求。这将为您提供更多并发性，帮助减少排队时间，并为您提供每个测功机的整体性能。