调试一个神秘的 Ruby 进程崩溃答案

【问题标题】：Debugging a mysterious Ruby process crash调试一个神秘的 Ruby 进程崩溃
【发布时间】：2015-01-19 08:46:21
【问题描述】：

我有一个 Ruby 进程在 m3.medium EC2 实例上连续运行，将队列中的内容渲染到 S3 中。它偶尔会死去（通常一天多次），没有明显的原因，也没有解释。

该应用程序由 elasticbeanstalk 部署，并从运行 ruby --verbose app.rb 的 ebextensions 脚本开始，并将错误和输出管道传输到文件（最初没有 --verbose，但我们添加了它以希望获得更多细节）。退出后，两个文件中都没有任何内容表明有任何错误。应用的顶层如下所示：

loop do
  begin
    do_processing
  rescue Exception => e
    puts "Error! #{e}"
  end
end

所以它不太可能自行退出或从异常中退出（我认为）。

服务器始终保持运行，并且没有耗尽内存。有时它会在峰值负载（高达 100% 的 CPU）时崩溃，但并非总是如此。

是否有 Ruby 工具可用于获取有关进程退出原因的更多信息？是否有可能我遇到了其他一些 EC2 或 Ruby 限制而关闭了进程？我可以做些什么来获得关于这里发生的事情的更多信息？

【问题讨论】：

这听起来不像是一个Ruby问题，如果进程在外部被杀死，而不是异常或段错误，你将不会获得任何相关信息AFAIK。试试/var/log/syslog，看看有没有线索。

标签： ruby debugging amazon-ec2 crash

【解决方案1】：

我们现在已经解决了这个问题：最终的问题是我们代码库深处的实际堆栈溢出。我们有一个装饰器泄漏，我们偶尔将我们的记录器包装在另一个日志装饰器中，因此日志记录变得越来越慢，最终变得太深并导致应用程序崩溃。解决了很多问题。

堆栈溢出以任何正常方式都无法捕获，并且由于没有剩余堆栈而无法将任何输出推送到日志，这听起来似乎是合理的，从而导致 Ruby 无声崩溃。这很好地解释了这一点，并且修复它已经为我们完全解决了这个问题。

对于将来尝试调试此类事情的人，如果这不是您的答案：请考虑使用事后调试 (http://bashdb.sourceforge.net/ruby-debug.html#Post_002dMortem-Debugging) 运行您的应用程序，以便它在崩溃时打开调试器，并查看它在哪里结束。我们发现我们的应用程序在日志记录中有很多层，问题很快就从那里变得明显。

【讨论】：