%20por%20algum%20tempo.png)
Então eu tenho esse cenário estranho: existe um servidor esse apache/passenger/Rails e alguns outros serviços. Por exemplo, o comando top em si leva 100% do tempo da CPU (também iostat e Ruby, outros processos parecem normais). A princípio pensei que este fosse o famoso bug futexBug futex_wait() do Linux(já que o processador é Xeon E5), mas este é o Centos 6.5 com kernel 3.2.13-grsec-xxxx-grs-ipv6-64, e isso parece não ser afetado pelo bug futex. Aqui está a saída do comando superior:
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 mostra que esses processos travam na chamada do sistema select()
# strace -p 1938
Process 1938 attached - interrupt to quit
select(12, [0 11], NULL, NULL, NULL^C <unfinished ...>
Process 1938 detached
Qual pode ser a razão para isso?
Responder1
Eu lutei com uma situação semelhante hoje. Meus amigos eram gdb
, rb_backtrace()
e rake debug
. E no meu caso, foi um loop while infinito em algumas raras circunstâncias.
Apenas rb_backtrace()
para imprimir o backtrace. No meu caso, foi impresso no log de erros do apache ( /var/log/apache2/error.log
).
Este backtrace está na ordem inversa do normal. Veja as últimas linhas e procure as linhas referentes ao código da sua aplicação. Em seguida, use um depurador Ruby para depurar logo antes dessa linha.
Esta postagemhttps://robots.thoughtbot.com/using-gdb-to-inspect-a-running-ruby-processfoi útil.