%20durante%20alg%C3%BAn%20tiempo.png)
Entonces tengo este extraño escenario: hay un servidor apache/passenger/Rails y algunos otros servicios. Por ejemplo, el comando superior en sí requiere el 100% del tiempo de CPU (también iostat y ruby, otros procesos parecen normales). Al principio pensé que este era el famoso error futex.Error futex_wait() de Linux(ya que el procesador es Xeon E5), pero este es Centos 6.5 con kernel 3.2.13-grsec-xxxx-grs-ipv6-64, y esto parece no verse afectado por el error futex. Aquí está el resultado del 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 muestra que estos procesos se bloquean en la llamada al sistema select()
# strace -p 1938
Process 1938 attached - interrupt to quit
select(12, [0 11], NULL, NULL, NULL^C <unfinished ...>
Process 1938 detached
¿Cuál puede ser la razón de esto?
Respuesta1
Luché con una situación similar hoy. Mis amigos eran gdb
, rb_backtrace()
y rake debug
. Y en mi caso, fue un bucle while infinito en algunas circunstancias excepcionales.
Sólo rb_backtrace()
para imprimir el seguimiento. En mi caso, se imprimió en el registro de errores de Apache ( /var/log/apache2/error.log
).
Este rastreo está en orden inverso al habitual. Vea las últimas líneas y busque líneas que hagan referencia al código de su aplicación. Luego, use un depurador Ruby para depurar justo antes de esa línea.
Esta publicaciónhttps://robots.thinkbot.com/using-gdb-to-inspect-a-running-ruby-processfue útil.