Question

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

该应用程序由elasticbeanstalk部署，并以运行ruby --verbose app.rb的ebextensions脚本启动，并将错误和管道传输到文件（最初没有--verbose，但我们已经添加了该文件以期更详细）。退出后，任一文件中都没有指示任何错误。该应用程序的顶级显示如下：

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

所以它不可能单独退出或从异常退出（我认为）。

服务器始终在运行，并且内存不足。有时它在峰值负载时崩溃（高达CPU的100％），但并非总是如此。

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

Answer 1

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

听起来似乎有理由说堆栈溢出不能以任何正常方式捕获，并且无法将任何输出推送到日志，因为没有剩余堆栈，从而产生静默的Ruby崩溃。这很整齐地解释了这一点，而且修复已经完全解决了这个问题。

对于未来尝试调试此类事情的人，如果这不是您的答案：请查看使用事后调试（http://bashdb.sourceforge.net/ruby-debug.html#Post_002dMortem-Debugging）运行您的应用程序，以便在崩溃时打开调试器，并查看位置它结束了。我们发现我们的应用程序在日志记录方面有很多层次，从那里很快就会出现问题。

调试神秘的Ruby进程崩溃

1 个答案: