%20%D0%BD%D0%B0%20%D0%BD%D0%B5%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D0%BE%D0%B5%20%D0%B2%D1%80%D0%B5%D0%BC%D1%8F.png)
Итак, у меня странный сценарий: есть сервер apache/passenger/Rails и некоторые другие сервисы. Например, сама команда top занимает 100% процессорного времени (также iostat и ruby, другие процессы кажутся нормальными). Сначала я думал, что это известный баг futexОшибка Linux futex_wait()(так как процессор Xeon E5), но это Centos 6.5 с ядром 3.2.13-grsec-xxxx-grs-ipv6-64, и это, похоже, не затронуто ошибкой 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было полезно.