Heroku上的Rails应用程序中的随机超时异常

我在Heroku上托管Rails 3.2应用程序，每天在Rails应用程序中获取2-3次超时。这些是而不是 H12请求超时，而是发生在Rails栈内某处的超时。因此，他们实际上在网站上生成了例外情况，并出现在我的Airbrake日志中。Heroku上的Rails应用程序中的随机超时异常

在超时发生时，它似乎是完全随机的;有时它在Formtastic之类的宝石中，或在HAML视图内，或在ActiveRecord代码中。你可以在这里看到一些回溯的例子：https://gist.github.com/dpmccabe/5238273

这个网站没有获得很多流量，并且在两个dynos上运行良好（尽管它们自动放大，这要归功于Adept Scale附加组件）。 HTTP_X_HEROKU_QUEUE_WAIT_TIME标头通常很低或为零，所以我不认为这是一个路由问题。我甚至尝试从Thin转换到Unicorn而没有任何效果（我的unicorn.rb显示在上面的要点中）。

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

来源

2013-03-25 Devin

这发生在我们的应用程序每天一次或两次...希望我可以提供更多的帮助，但我在同一条船！ – stereoscott 2013-04-18 02:36:17

+1我也看到这个，在15s/Heroku Cedar的Unicorn/Rails 3.2/Rack-Timeout。如果我能发现它们，我会按照此线程发布更多细节。 – 2013-05-15 17:56:54

只是好奇：在超时时间内你的平均吞吐量（RPM）是多少？ – KendallB 2013-06-14 16:04:59

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

Rack::Timeout.timeout = 15 # seconds

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

来源

2013-04-20 10:07:15 dpaluy

我也已经运行到了同样的问题。尽管我还没有解决这个问题，但我还是认为我会和我目前看到的一样。我正在使用机架超时宝石（基于你的回溯，它看起来像你一样），并将超时设置为15秒。看看新的文物，任何请求的平均应用服务器响应时间远低于200毫秒。然而，像你这样，我每天都会收到看起来像这样的错误2-3：发生在一个广泛的行动

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

的错误，没有行动似乎是特别容易产生一个。该错误甚至发生在简单的CRUD DELETE操作上。我在Heroku的Cedar堆栈上运行rails 3.2应用程序。我运行了两个网络游戏机，每个都有3名独角兽工作人员。他们每个人始终保持低于512mb的限制。

我到目前为止发现的唯一线索就是我经常看到这样的靠近我超时以下在我的日志：

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

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

来源

2013-04-26 02:51:36 middkidd

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

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

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

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

再次，这可能不是你的问题的答案，但这是我解决我的问题。希望它有帮助！

来源

2013-07-19 15:37:22

我使用以下关闭日志记录： Rack :: Timeout.unregister_state_change_observer（：logger） – 2015-01-28 15:29:42

Heroku上的Rails应用程序中的随机超时异常

回答

相关问题