Rails：执行在 time_zone_select 过期答案

【问题标题】：Rails: execution expired on time_zone_selectRails：执行在 time_zone_select 过期
【发布时间】：2013-03-13 00:24:10
【问题描述】：

间歇性出现以下异常：

An ActionView::Template::Error occurred

execution expired
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `require'

这是完整的跟踪：

vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `require'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `block in require'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:236:in `load_dependency'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:251:in `require'
vendor/bundle/ruby/1.9.1/gems/tzinfo-0.3.37/lib/tzinfo/timezone.rb:103:in `get'
vendor/bundle/ruby/1.9.1/gems/tzinfo-0.3.37/lib/tzinfo/timezone_proxy.rb:80:in `real_timezone'
vendor/bundle/ruby/1.9.1/gems/tzinfo-0.3.37/lib/tzinfo/timezone_proxy.rb:52:in `period_for_utc'
vendor/bundle/ruby/1.9.1/gems/tzinfo-0.3.37/lib/tzinfo/timezone.rb:458:in `current_period'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/core_ext/object/try.rb:36:in `try'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/values/time_zone.rb:212:in `utc_offset'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/values/time_zone.rb:226:in `<=>'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/values/time_zone.rb:334:in `sort'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/values/time_zone.rb:334:in `all'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_view/helpers/form_options_helper.rb:507:in `time_zone_options_for_select'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_view/helpers/form_options_helper.rb:612:in `to_time_zone_select_tag'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_view/helpers/form_options_helper.rb:277:in `time_zone_select'
vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.13/lib/action_view/helpers/form_options_helper.rb:654:in `time_zone_select'

当我导航到相关页面时，它可以正常加载。对于大多数人来说，它似乎加载得很好，而且只是间歇性地（很少）像这样崩溃。我注意到，无论何时发生，用户代理都是机器人。最近的是Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)。但我担心有一天它可能会发生在人类身上，所以我想知道是否有人知道我能对此做些什么？

更新

这是今天出现的，有一个用户登录（幸运的是，那个用户是我……但无法复制它）。

execution expired
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:15:in `visit'

追踪：

vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:15:in `visit'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:5:in `accept'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:36:in `block in visit_Psych_Nodes_Sequence'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:36:in `each'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:36:in `visit_Psych_Nodes_Sequence'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:15:in `visit'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:5:in `accept'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:26:in `block in visit_Psych_Nodes_Document'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:26:in `each'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:26:in `visit_Psych_Nodes_Document'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:15:in `visit'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:5:in `accept'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:20:in `block in visit_Psych_Nodes_Stream'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:20:in `each'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/emitter.rb:20:in `visit_Psych_Nodes_Stream'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:15:in `visit'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/visitors/visitor.rb:5:in `accept'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/nodes/node.rb:46:in `yaml'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych.rb:243:in `dump'
vendor/bundle/ruby/1.9.1/gems/psych-1.3.4/lib/psych/core_ext.rb:14:in `psych_to_yaml'
/usr/local/lib/ruby/1.9.1/syck/rubytypes.rb:110:in `to_yaml'
vendor/bundle/ruby/1.9.1/gems/dalli-delete-matched-1.1.0/lib/dalli-delete-matched.rb:13:in `write_entry'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/cache/strategy/local_cache.rb:140:in `write_entry'
vendor/bundle/ruby/1.9.1/gems/dalli-2.6.2/lib/active_support/cache/dalli_store.rb:102:in `block in write'
vendor/bundle/ruby/1.9.1/gems/dalli-2.6.2/lib/active_support/cache/dalli_store.rb:279:in `block in instrument'
vendor/bundle/ruby/1.9.1/gems/activesupport-3.2.13/lib/active_support/notifications.rb:125:in `instrument'
vendor/bundle/ruby/1.9.1/gems/dalli-2.6.2/lib/active_support/cache/dalli_store.rb:279:in `instrument'
vendor/bundle/ruby/1.9.1/gems/dalli-2.6.2/lib/active_support/cache/dalli_store.rb:101:in `write'
vendor/bundle/ruby/1.9.1/gems/dalli-2.6.2/lib/active_support/cache/dalli_store.rb:78:in `fetch'
app/models/concerns/roleable.rb:11:in `roles'

同样，我们非常欢迎任何见解！

我在 Heroku 上托管这个，并按照 https://blog.heroku.com/archives/2013/2/27/unicorn_rails 的说明使用 Unicorn

【问题讨论】：

这种情况会发生在控制器的一个特定操作上吗？
不，这两个堆栈跟踪来自不同的控制器。
你查到这个错误的根源了吗？我在heroku上也看到了同样的错误。我的堆栈跟踪看起来与您的第一个堆栈跟踪相似。
@Clark - 它非常断断续续。我不想说它是“固定的”，但它发生的次数越来越少，尽管我没有（有意识地）做任何事情来解决这个特定的问题——除了调整我的 Unicorn 超时设置并添加另一个测功机（我正在计划无论如何做）。如果您有任何发现，请告诉我/发布答案！
我的预感是它是由等待 heroku 的文件系统引起的。我已将超时变量从 heroku 网站上建议的 10 秒增加到 25 秒...将进行监控

标签： ruby-on-rails actionview activesupport

【解决方案1】：

由于两个堆栈跟踪完全不同，我冒昧地认为页面渲染通常会花费大量时间，并且与特定堆栈跟踪中显示的内容无关：ActionView 将在超时发生时停止。

您应该尝试加快渲染过程，例如使用缓存：让机器人只访问从缓存提供的非动态内容以减少服务器负载。甚至将大页面拆分为部分并缓存它们可能会有所帮助。

如果您仍然遇到这种情况 - 特别是因为这种情况非常罕见 - 您可以在发生此异常时自动重新呈现页面。示例代码见this blog entry。

【讨论】：

【解决方案2】：

回答这个问题：

我真的很想解决这个问题，但我真的没有想法从哪里开始：/

你可以开始挽救这个错误，记录它，给你发送一封电子邮件，因为它只发生几次，所以重试（使用“重试”命令）。在此之后，您可能需要检查此 IP 执行的最后操作并查看它是否相关。 Log 还记录会话变量。

也许您在服务器使用率高时遇到了超时 - 尝试使用一种工具 lime newrelic 甚至自己记录内存使用情况、cpu 使用情况和磁盘使用情况以及其他信息。

编辑：

因为它不仅仅是一个动作，你可以像这样在 ApplicationController 上得到每个错误：

class ApplicationController < ActionController::Base
  rescue_from MyException, :with => :handle_my_exception

  def handle_my_exception
     grab_data
     send_mail
     retry
  end
 end

我认为这是针对特定操作的，所以我不确定重试是否在这里有效。但即使您无法重试，您仍然可以通过这种方式获取更多信息并通过电子邮件发送给自己。当然你会想要添加一个重试计数器逻辑，否则你会遇到麻烦。

再次编辑：

想得更好，您可以根据请求参数使用redirect_to 从那里模拟重试。在这个答案中，他解释了如何获得它。不要忘记也发送参数。

How do I get the current absolute URL in Ruby on Rails?

【讨论】：

救援/重试代码会去哪里？在render 调用的控制器中，还是在视图中？
我添加了一些代码示例，说明如何做我想做的事情。但不确定重试是否会正常工作:(
关于发送邮件：看看github.com/smartinez87/exception_notification它发送了一封非常有用的邮件。
是的，我正在使用 exception_notification 来获取提醒我注意这一点的电子邮件 :)

【解决方案3】：

这个问题（无论如何在 Heroku 上）归结为以下代码：

ActiveSupport::TimeZone::MAPPING.each do |key,val|
  TZInfo::Timezone.get(val)
end

所有时区信息都是从一组相当大的文件（每个时区一个）中加载的，然后进行解析。由于某种原因，此操作非常繁重。也许是 Ruby 在基于文件的 IO 方面效率不高（？）和 Heroku dynos 在文件系统中遇到随机问题的组合。

我目前的解决方法是在所有 Unicorn 工作人员 (after_fork) 中预加载时区信息（基本上运行上述代码）。现在至少问题是确定性的，而不是随机发生的......

【讨论】：