所以我遇到了一个奇怪的场景:有一台服务器,这个 apache/passenger/Rails 和一些其他服务。例如 top 命令本身占用了 100% 的 CPU 时间(iostat 和 ruby 也是如此,其他进程似乎很正常)。起初我以为这是著名的 futex 错误Linux futex_wait() 错误(因为处理器是 Xeon E5),但这是带有 3.2.13-grsec-xxxx-grs-ipv6-64 内核的 Centos 6.5,这似乎不受 futex 错误的影响。以下是 top 命令的输出:
top - 18:14:46 up 60 days, 6:32, 2 users, load average: 2.15, 1.24, 1.04
Tasks: 180 total, 1 running, 179 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.0%sy, 0.0%ni, 95.0%id, 1.7%wa, 0.0%hi, 0.7%si, 0.0%st
Mem: 66008460k total, 21226356k used, 44782104k free, 817252k buffers
Swap: 61437944k total, 0k used, 61437944k free, 17404540k cached
Change delay from 3.0 to:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18042 root 20 0 15076 1272 904 S 100.0 0.0 5109402h top
18041 root 20 0 105m 1192 1028 S 100.0 0.0 900776:13 sh
18043 root 20 0 98.6m 808 692 S 100.0 0.0 900776:13 iostat
1 root 20 0 19276 1508 1228 S 0.0 0.0 0:02.40 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.02 kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 5119411h ksoftirqd/0
5 root 20 0 0 0 0 S 0.0 0.0 10218485h kworker/u:0
6 root RT 0 0 0 0 S 0.0 0.0 986912:21 migration/0
7 root RT 0 0 0 0 S 0.0 0.0 906076:59 migration/1
9 root 20 0 0 0 0 S 0.0 0.0 45038,51 ksoftirqd/1
11 root RT 0 0 0 0 S 0.0 0.0 911444:25 migration/2
13 root 20 0 0 0 0 S 0.0 0.0 120103,33 ksoftirqd/2
14 root RT 0 0 0 0 S 0.0 0.0 941393:43 migration/3
strace 表明这些进程挂在 select() 系统调用上
# strace -p 1938
Process 1938 attached - interrupt to quit
select(12, [0 11], NULL, NULL, NULL^C <unfinished ...>
Process 1938 detached
这是什么原因造成的?
答案1
我今天也遇到了类似的情况。我的朋友是gdb
,rb_backtrace()
和rake debug
。而就我而言,在一些罕见的情况下,这是一个无限的 while 循环。
只是rb_backtrace()
为了打印出回溯。在我的例子中,它被打印在 apache 的错误日志中 ( /var/log/apache2/error.log
)。
此回溯的顺序与通常的顺序相反。查看最后几行,并查找引用应用程序代码的行。然后,使用 ruby 调试器在该行之前进行调试。
这个帖子https://robots.thoughtbot.com/using-gdb-to-inspect-a-running-ruby-process很有帮助。