当我发送一个GET请求到rails服务器需要很长时间来响应(29分钟)
下面是日志片段日志说代码中有错误,这是可以的,但是为什么需要这么长时间才能响应(1723579毫秒)我无法找到这种行为的任何原因。以前,当服务器工作正常时,这个js请求只需要9毫秒来响应。但突然它开始像这样。我应该如何调试应用程序以跟踪这种意外行为的根本原因?
Started GET "/my-server/jobs/workers?_=1356363515400" for 27*.*.*.* at 2012-12-24 21:08:35 +0530
ActionView::Template::Error ():
1: <% @jobs.each do |job| %>
2: $('#cron_<%= job.id %>').attr('data-content', '<%= distance_of_time_in_words_to_now(job.next_fire_info, true) %>');
3: <% end %>
4:
5: <% @workers.each do |worker| %>
app/models/job.rb:16:in `next_fire_info'
app/views/jobs/workers.js.erb:2:in `block in _app_views_jobs_workers_js_erb__101155230_81985760'
app/views/jobs/workers.js.erb:1:in `_app_views_jobs_workers_js_erb__101155230_81985760'
Rendered jobs/workers.js.erb (1718348.7ms)
Completed 500 Internal Server Error in 1723579ms
我正在使用Rails 3.1.3,Ruby 1.9.3p194,MongoDB版本v2.2.0, pdfile版本4.5,32位Ubuntu (12.04), 2gb内存
3.1.5之前的rails 3.1版本有一个bug,当从视图中引发异常时,rails需要很长时间才能生成异常消息。
如果你不能更新到3.1.5,修复方法很简单(参见修复它的提交)——你只需要执行monkey patch inspect:
module ActionDispatch
module Routing
module RouteSet
alias to_s inspect
end
end
end
我以前把它转储到初始化器中。还有一个gem (safe_inspect)声称可以为您完成此操作,尽管我从未尝试过。
我终于找到了这么长时间才回复的原因。工作线程基于cron表达式周期性运行。此特定问题的根本原因是错误地输入了job的一个cron表达式。这就是为什么在执行"distance_of_time_in_words_to_now"时花费太多时间的原因。
我有类似的问题,这是由身份验证引起的,所以这只是为了记录,如果有人在未来有同样的问题。服务器不允许用户进入,然后重定向到受限制的页面,等等,等等