Servidor que se cuelga por razones no tan obvias

Sistema:

Linux v22017032713145956 3.16.0-4-amd64 #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) x86_64 GNU/Linux
Este es un server virtualizado que se ejecuta en un nodo con virtualización KVM.

Que he hecho:

  • Quería ejecutar un server de juegos de factoría. Así que lo descargué y lo ejecuté. (Esto fue en marzo)
  • Después de unos días, el server simplemente se colgó. No tengo ningún logging de esto junto a un correo electrónico que solicite mi apoyo si un post del kernel acerca de los rcu_sched detected stalls on cpu tiene algo que ver con el nodo en el que se está ejecutando el server.
  • Apoyo dijo que debería intentar configurar el planificador de E / S en noop
  • Configuré el planificador en consecuencia (pero solo temporalmente haciendo eco de noop en el file sys)
  • Todo funcionó bien durante aproximadamente un mes
  • Hice actualizaciones regulares de los repositorys de Debian (solo jessie y jessie-updates, sin backports o algo experimental de ningún tipo)
  • Hice actualizaciones regulares de los repositorys de Froxlor y GitLab.
  • El server queuepsó nuevamente alnetworkingedor de las 4:00 am del 29 de abril sin ningún motivo aparente.
  • Reinicié el server desde el panel de control del nodo el 1 de mayo.
  • Se estrelló nuevamente el mismo día. Esta vez no inicié el server de factoría ni cambié el planificador de E / S.

Información adicional

Respuestas de ping

El monitoreo informó que el server no responde a pings entre:

  • 04-29-2017 04:07:30 -> 04-30-2017 09:55:46
  • 05-01-2017 11:08:52 -> 05-01-2017 11:16:54

Registro Kernel

/var/log/kern.log en estos frameworks de time:

  • del 23 de abril al 30 de abril
  • del 1 de mayo al 3 de mayo
  • desde el 3 de mayo

Hora de preguntar

¿Cuál es el problema? No recuerdo haber instalado nada.
¿Cómo puedo depurar el post de rcu_sched detected stalls ?

Actualización del 7 de mayo

Acabo de recibir un post de text de mi amigo, que el server se está comportando de manera extraña. Así que revisé los loggings y nuevamente hay puestos. Cargué el último logging .

Actualización del 8 de mayo

Acabo de ejecutar memtest86 + y no encontré nada. Pero revisé el gráfico de CPU de los últimos 31 días y encontré algo interesante: Carga de CPU Cuando el server dejó de responder por primera vez a los pings, la carga de la CPU en el núcleo 2 se descompuso, mientras que todos los otros núcleos estaban inactivos. El pico en CPU0 fue memtest.

Actualización del 7 de junio

Informes de time de actividad:
10:05:05 up 27 days, 20:50, 1 user, load average: 0.23, 0.25, 0.18
Pero apagué GitLab. ¿Alguien ha experimentado con GitLab causando problemas en Debian?

Como se ve en sus loggings, supongo que sus problemas probablemente se deben a adiciones de VirtualBox Guest instaladas en una máquina KVM VM, y que tienen algún tipo de conflicto.

De vboxdrv module del kernel vboxdrv parecía haber sido desinstalado y reemplazado por los controlleres kvm / virtio en el package anterior, creo , y algo que no parecía estar sucediendo en el nuevo por algún motivo.

Como dijo, después de los loggings que nos brinda, desinstaló los componentes de Virtual Box.

OMI, tomaste la acción correcta. Ahora dale unos días para ver si esto sucede nuevamente.

De los loggings, hubo algunos NMI, consulte: https://en.wikipedia.org/wiki/Non-maskable_interrupt

sugiero que revises tu hardware también.