我有来自 mod_rails 的 ruby 实例变成“流氓”——这些进程不再列在乘客状态中，并且使用 100% cpu。
除了安装 God/monit 来杀死实例之外，任何人都可以给我一些关于如何防止这种情况的建议吗？我无法在日志中找到任何有用的东西。
lamplighter
问问题
7538 次
4 回答
11
If you're using Linux, you can install the "strace" utility to see what the Ruby process is doing that's consuming all the CPU. That will give you a good low-level view. It should be available in your package manager. Then you can:
$ sudo strace -p 22710
Process 22710 attached - interrupt to quit
...lots of stuff...
(press Ctrl+C)
Then, if you want to stop the process in the middle and dump a stack trace, you can follow the guide on using GDB in Ruby at http://eigenclass.org/hiki.rb?ruby+live+process+introspection, specifically doing:
gdb --pid=(ruby process)
session-ruby
stdout_redirect
(in other terminal) tail -f /tmp/ruby_debug.(pid)
eval "caller"
You can also use the ruby-debug Gem to remotely connect to debug sockets you open up, described in http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger
There also seems to be a project on Github concerned with debugging Passenger instances that looks interesting, but the documentation is lacking: http://github.com/ddollar/socket-debugger/tree/master
于 2009-03-24T21:17:33.570 回答
4
我有一个与 Phusion Passenger 相关的 ruby 进程，它消耗了大量的 CPU，尽管它应该是空闲的。
我跑了之后问题就消失了
date -s "`date`"
正如这个线程中所建议的那样。（那是在 Debian Squeeze 上）
显然，这个问题与闰秒有关，并且可能影响许多其他应用程序，如 MySQL、Java 等。更多信息请参见lklm 上的此线程。
于 2012-10-24T08:27:01.623 回答
2
我们在运行很长时间的 SQL 查询中看到了类似的情况。
MySQL 将终止查询，因为它们超出了长期运行限制，并且线程从未意识到查询已死。
您可能需要检查数据库日志。
于 2009-03-30T21:14:21.190 回答
2
这是乘客反复出现的问题。我已经多次看到这个问题帮助那些在轨道上运行 ruby 的人。我没有修复，但你可能想试试这个http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen
于 2009-03-08T13:00:04.603 回答