BUG: soft lockup - CPU

Latencia de red (en ms)
Ayer me pasó algo curioso en unas máquinas virtuales bajo XenServer. Hay que decir que estas máquinas están virtualizadas en una infraestructura a la que no hay acceso y sobre la que no sabemos qué tipo de máquinas hay, a mayores de las nuestras. El caso es que todas las nuestras se estaban a ejecutar en mismo nodo del clúster y sin más ni más, comenzaron a subir el uso de CPU y su latencia de red. Gracias a #zabbix, su perfecta monitorización y sus alertas nos pudimos enterar al momento. Dejo un par de gráficas que representan las subidas experimentadas, que como se pueden ver, son considerables.
Consumo de CPU
Lo sorprendente es que la carga de las máquinas se originó sin motivo aparente, ya que no hubo nada "extraño" en la red ni en las máquinas, según las primeras palabras del proveedor. Sin embargo, tras revisar un poco de log's, nos encontramos con el siguiente fallo,
kernel: [12005213.706327] BUG: soft lockup - CPU#0 stuck for 64s! [kjournald:908]
kernel: [12005213.706327] Modules linked in: iptable_filter ip_tables x_tables firewire_sbp2 firewire_core crc_itu_t loop snd_pcm snd_timer parport_pc i2c_piix4 snd i2c_core joydev soundcore snd_page_alloc pcspkr parport processor evdev button psmouse serio_raw ext3 jbd mbcache usbhid hid sg sr_mod cdrom sd_mod crc_t10dif ata_generic ata_piix uhci_hcd 8139too ehci_hcd thermal libata floppy thermal_sys 8139cp mii usbcore nls_base scsi_mod [last unloaded: scsi_wait_scan]
kernel: [12005213.706327]
kernel: [12005213.706327] Pid: 908, comm: kjournald Not tainted (2.6.32-5-686 #1) HVM domU
kernel: [12005213.706327] EIP: 0060:[] EFLAGS: 00000282 CPU: 0
kernel: [12005213.706327] EIP is at cp_interrupt+0x23/0x28a [8139cp]
kernel: [12005213.706327] EAX: f7dea03e EBX: c1360aa0 ECX: c1360aa0 EDX: f6f60001
kernel: [12005213.706327] ESI: f6f62ba0 EDI: 00000020 EBP: f6f62800 ESP: e770fcf4
kernel: [12005213.706327]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
kernel: [12005213.706327] CR0: 8005003b CR2: f8260ffc CR3: 36f58000 CR4: 000006d0
kernel: [12005213.706327] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
kernel: [12005213.706327] DR6: ffff0ff0 DR7: 00000400
Lo más sorprendente que hemos encontrado ha sido la línea de BUG destacada en los log's y el posterior trace completo que hace. Tras investigar un poco a qué pudo ser debido, todo apunta a un fallo en la reserva de IRQ de las máquinas, lo que provocó un incremento de la carga de todos los equipos.
Por lo que hemos podido averiguar a posteriori, el proveedor sí nos reconoció que algunas de las máquinas del clúster efectivamente estaban consumiendo un gran ancho de banda, lo que afectó a las otras, que estaban mucho más ociosas. Se ve que la virtualización todavía no es 100% efectiva bajo ciertas circunstancias.


No hay comentarios :

Publicar un comentario

Formulario de contacto

Nombre

Correo electrónico *

Mensaje *

Últimos comentarios