Heroku / Unicorn上的重复出现轨道错误 - '执行过期'，一个ActionView :: Template :: Error [英] Recurring rails error on Heroku/Unicorn - 'execution expired', an ActionView::Template::Error

问题描述

我的问题与以下内容类似，但发生在稍微不同的情况下。

Rails：执行在time_zone_select上过期

我的设置是：

• Rails 3.2.13


• Unicorn 4.6.2


• Mongoid 3.0。 22


• Moped 1.4.2

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

这些错误分批发送，通常通过Heroku进程重启来解决。第一个通常是下面的那个：

 在[controller]＃[action]中出现了一个ActionView :: Template :: Error： 
 
执行过期
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / sockets / connectable.rb：46：在`read'
  

以下是堆栈跟踪的最高位。如果需要，欢迎加入更多！

  vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / sockets / connectable。 rb：46：在`read'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / sockets / connectable.rb：46：在`block in read'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / sockets / connectable.rb：118：在`handle_socket_errors'
 vendor / bundle / ruby​​ / 1.9.1 / gem / moped-1.4.2 / lib / moped / sockets / connectable.rb：46：在`read'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped /连接.rb：177：在`read_data'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / connection.rb：99：在`block in read'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / connection.rb：202：在`with_connection'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / connection.rb：97：在`read'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / protocol / query中。 rb：163：在`receive_replies'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / connection.rb：135：in`block in r eceive_replies'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / connection.rb：134：在`map'
 vendor / bundle / ruby​​ / 1.9。 1 / gems / moped-1.4.2 / lib / moped / connection.rb：134：在`receive_replies'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / 
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / node.rb：129：在`block（2 levels）in flush' $_b $ vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / node.rb：551：在`block in flush'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / node.rb：566：在`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：在`query'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / cursor.rb：138：在load_docs块中$ b $ vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / session /上下文.rb：105：在`block in with_node'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / cluster.rb：250：在`with_secondary'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / session / context.rb：104：在`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：在`each'
 vendor / bundle / ruby​​ / 1.9.1 / gems / moped-1.4.2 / lib / moped / query.rb：76：在`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`在每个'
 vendor / bundle / ruby​​ / 1.9.1 / gems / mongoid-3.0.22 / lib / mongoid / contextual / mongo.rb ：556：在`选择'
 vendor / bundle / ruby​​ / 1.9.1 / gems / mongoid-3.0.22 / lib / mongoid / contextual / mongo.rb：131：在`each'
 vendor /bundle/ruby/1.9.1/gems/mongoid-3.0.22/lib/mongoid/contextual.rb:18:in`each'
  

Rack :: Timeout设置为10秒（我相信这是我读过的一个缓存教程提出的） - 如果答案是增加超时时间，那很好。但我不知道这是不是一个缓慢的查询问题？这种行为似乎表明它只是挂起的一个独角兽进程（这就是为什么ps重启似乎可以治愈它）。

任何想法或提示都会非常感谢！

解决方案

我建议这是heroku的文件或网络系统的问题。 mod的read方法调用'Kernel :: select。选择它是一个系统阻塞调用，它将等待IO对象变得可读。在这种情况下，它是通过外部连接到MongoLab的TCP端口。可能有多种原因导致TCP端口无法读取。网络和文件问题浮现在脑海。我怀疑这是一个长时间运行的查询，因为在查询的运行过程中，套接字是可读的，select不会阻止脚本执行。如果问题依然存在，我会考虑从heroku或者另一个网络上的外部数据库移开。 AWS始终是一个不错的选择，因为它们在boxen（box）之间的延迟非常低。 HTH

My question is similar to the following, but is happening under slightly different circumstances.

Rails: execution expired on time_zone_select

My setup is:

• Rails 3.2.13
• Unicorn 4.6.2
• Mongoid 3.0.22
• Moped 1.4.2

Running on Heroku Cedar. MongoDB is hosted at MongoLab.

The errors come in batches and are often solved by a Heroku process restart. The first is usually the one below:

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'

The following is the top bit of the stack trace. Happy to add more if needed!

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 is set for 10 seconds (I believe that was suggested by one of the caching tutorials I read) -- if the answer is to increase the timeout, that's fine. But I wonder if this isn't a slow query issue? The behavior seems to indicate that it's just one of the Unicorn processes that gets hung up (which is why a ps restart seems to cure it).

Any thoughts or tips would be hugely appreciated!

解决方案

I would suggest this is an issue with heroku's file or network system. The modped read method calls' Kernel::select. Select it's self is a system blocking call that will wait for IO objects to become readable. In this case it's the TCP port that makes the external connection to MongoLab. There could be any number of reasons for the TCP port to be come unreadable. Networking and file issues come to mind. I doubt it's a long running query as the socket would be readable during the running of the query there for select would not block the script execution. If the issue persists I would consider moving away from heroku or perhaps an external database on a different network. AWS is always a good choice as they have very low latency between boxen(boxes). HTH

这篇关于Heroku / Unicorn上的重复出现轨道错误 - '执行过期'，一个ActionView :: Template :: Error的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！