11

我在 Heroku 上托管了一个 Rails 3.2 应用程序，并且每天在 Rails 应用程序中出现 2-3 次超时。这些不是H12 请求超时，而是发生在 Rails 堆栈中某处的超时。因此，它们实际上会在站点上生成异常并出现在我的 Airbrake 日志中。

超时发生的地方似乎是完全随机的；有时它在像 Formtastic 这样的 gem 中，或者在 HAML 视图中，或者在 ActiveRecord 代码中。您可以在此处查看一些回溯的示例：https ://gist.github.com/dpmccabe/5238273

该站点没有获得太多流量并且在两个测功机上运行良好（尽管由于 Adept Scale 附加组件它们会自动扩展）。HTTP_X_HEROKU_QUEUE_WAIT_TIME 标头通常较低或为零，因此我认为这不是路由问题。我什至尝试从 Thin 切换到 Unicorn，但没有任何效果（我的 unicorn.rb 显示在上面的要点中）。

这些超时异常似乎在整个应用程序中随机发生的事实并没有给我太多继续。我确实有 New Relic，但我不确定如何调试它。有任何想法吗？

4

3 回答 3

1

我也遇到了同样的问题。虽然我还没有解决它，但我想我会加入我目前所看到的内容。我正在使用 rack-timeout gem（根据您的回溯，看起来您也是如此）并将超时设置为 15 秒。看看新的遗物，我对任何请求的平均应用服务器响应时间都远低于 200 毫秒。然而，像你一样，我每天会遇到 2-3 个错误，如下所示：

undefined method `result' for #<Timeout::Error: execution expired>

错误发生在范围广泛的操作上，似乎没有任何操作特别容易产生错误。该错误甚至发生在简单的 CRUD DELETE 操作上。我在 Heroku 的 Cedar 堆栈上运行 rails 3.2 应用程序。我运行两个网络 dyno，每个都有 3 个独角兽工人。它们每个都始终保持在 512mb 限制以下。

到目前为止，我发现的唯一线索是，我经常在日志中的超时附近看到类似以下内容：

[AMBER] LOG: process 21289 acquired ShareLock on transaction 105259 after 32366.132 ms

你看到类似的东西吗？锁定记录的数据库操作可能会导致超时，我不太确定。

于 2013-04-26T02:51:36.690 回答
1

我在 Heroku 上托管的应用程序中遇到了同样的问题。

我检查了日志，发现处理时间超过 30 秒的请求很少，导致 heroku 出现超时错误。在我的情况下，问题是打印到日志，我有一个登台服务器，它有很多输入和输出数据打印到服务器日志，打印时间超过 30 秒，heroku 会假设请求仍在处理中，即使之后响应是从远程 api 收到的，因为它还没有完成将数据打印到日志中。

因此，我删除了所有将输入（由代码构造的输入 xml 数据）和输出（从 api 接收的 xml 数据）数据打印到日志的打印语句。

  1. 所以我建议你检查日志，看看请求是否需要超过 30 秒来处理
  2. 检查您是否正在打印需要时间在日志上打印的数据（用于调试目的）。

同样，这可能不是您问题的答案，但这就是我解决问题的方法。希望能帮助到你！

于 2013-07-19T15:37:22.970 回答
0

根据Heroku Dev Center的说法，如果完成时间超过 30 秒，路由器将终止请求。您可以使用rack-timeout gem来查找瓶颈。只要让你的超时时间少于 30 秒

Rack::Timeout.timeout = 15 # seconds

如果您有多个并行请求，请考虑使用Unicorn

于 2013-04-20T10:07:15.710 回答