Heroku/Unicorn 上反复出现 Rails 错误 - “执行已过期”，ActionView::Template::Error

Posted 2023-03-10

【中文标题】Heroku/Unicorn 上反复出现 Rails 错误 - “执行已过期”，ActionView::Template::Error

【英文标题】：Recurring rails error on Heroku/Unicorn - 'execution expired', an ActionView::Template::Error

【发布时间】：2013-05-20 10:11:06

【问题描述】：

我的问题与以下类似，但发生的情况略有不同。

Rails: execution expired on time_zone_select

我的设置是：

Rails 3.2.13 独角兽 4.6.2 Mongoid 3.0.22 助力车 1.4.2

在 Heroku Cedar 上运行。 MongoDB 托管在 MongoLab。

错误是分批出现的，通常通过重启 Heroku 进程来解决。第一个通常是下面的：

An ActionView::Template::Error occurred in [controller]#[action]:

 execution expired
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read'

以下是堆栈跟踪的最高位。如果需要，很高兴添加更多！

vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `block in read'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:118:in `handle_socket_errors'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/sockets/connectable.rb:46:in `read'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:177:in `read_data'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:99:in `block in read'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:202:in `with_connection'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:97:in `read'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/protocol/query.rb:163:in `receive_replies'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:135:in `block in receive_replies'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `map'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/connection.rb:134:in `receive_replies'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:553:in `block (2 levels) in flush'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:129:in `ensure_connected'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:551:in `block in flush'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:566:in `logging'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:550:in `flush'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:539:in `process'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/node.rb:349:in `query'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:138:in `block in load_docs'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:105:in `block in with_node'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cluster.rb:250:in `with_secondary'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/session/context.rb:104:in `with_node'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:137:in `load_docs'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/cursor.rb:25:in `each'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each'
 vendor/bundle/ruby/1.9.1/gems/moped-1.4.2/lib/moped/query.rb:76:in `each'
 vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:132:in `block in each'
 vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:556:in `selecting'
 vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual/mongo.rb:131:in `each'
 vendor/bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual.rb:18:in `each'

Rack::Timeout 设置为 10 秒（我相信这是我阅读的缓存教程之一所建议的）——如果答案是增加超时，那很好。但我想知道这是否不是一个缓慢的查询问题？该行为似乎表明它只是挂起的 Unicorn 进程之一（这就是为什么 ps 重新启动似乎可以治愈它的原因）。

任何想法或提示将不胜感激！

【问题讨论】：

我在 EC2 上看到了同样的问题/堆栈跟踪，堆栈非常相似。

这不是问题的解决方案，而是一个轻微的解决方法（不一定是一个好的解决方法）——我将 Unicorn 换成 Puma 并在 Heroku 上增加了 2 个 Dynos，问题已经减少了一个很大的因素。但它仍然没有解决，我每天仍然会遇到一些“执行过期”错误（从几个小时下降）。我的直觉是这是一个 Mongoid/MongoLab 问题 - 查询响应缓慢或与非本地数据库挂起打开的连接。

更新 #2：它仍然经常发生，即使使用 2 dynos 和 puma 而不是 Unicorn。叹息。

@NoahLehmann-Haupt 你有多少独角兽工人？您可以将您的 unicorn.rb 文件粘贴到您的问题中吗？另外，您是否仅通过 Mongo 的控制台确认查询实际上很慢？最后，很高兴看到您的控制器代码。

@NoahLehmann-Haupt 你有没有解决这个问题？我也有类似的问题。

【参考方案1】：

尝试在 Gemfile 中将 ruby​​ 版本设置为 1.9.3，然后再次打包、提交和部署

【参考方案2】：

我认为这是heroku 的文件或网络系统的问题。修改后的读取方法调用'Kernel::select。 Select it's self 是一个系统阻塞调用，它将等待 IO 对象变为可读。在这种情况下，与 MongoLab 建立外部连接的是 TCP 端口。 TCP 端口无法读取的原因可能有很多。网络和文件问题浮现在脑海。我怀疑这是一个长时间运行的查询，因为在查询运行期间套接字将是可读的，因为 select 不会阻止脚本执行。如果问题仍然存在，我会考虑离开 heroku 或者可能是不同网络上的外部数据库。 AWS 始终是一个不错的选择，因为它们在 boxen(boxes) 之间的延迟非常低。高温