Tengo problemas con una máquina virtual Ubuntu 18.08 en Azure. El problema parece ocurrir cuando descomprimo un archivo grande con extensión unzip. Mi sesión SSH falla send disconnect: Broken pipey ya no puedo conectarme mediante SSH a la máquina hasta que la reinicie en la consola de Azure.
Revisé el espacio en disco y parece estar bien. Creo que el problema se debe a un bloqueo de la CPU que descubrí en los registros de diagnóstico:
[ 9574.275457] rcu: blocking rcu_node structures:
[ 9581.022803] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9609.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9614.067067] audit: backlog limit exceeded
[ 9614.072016] audit: backlog limit exceeded
[ 9614.076728] audit: backlog limit exceeded
[ 9637.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9665.022801] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9674.339074] audit: backlog limit exceeded
[ 9674.344825] audit: backlog limit exceeded
[ 9674.351922] audit: backlog limit exceeded
[ 9693.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9721.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]
[ 9734.182947] audit: backlog limit exceeded
[ 9734.188086] audit: backlog limit exceeded
[ 9734.194938] audit: backlog limit exceeded
[ 9736.682801] rcu: INFO: rcu_sched self-detected stall on CPU
[ 9736.684975] rcu: 1-....: (509855 ticks this GP) idle=492/1/0x4000000000000002 softirq=1049753/1049838 fqs=254454
[ 9754.486826] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 511745 jiffies s: 525 root: 0x2/.
[ 9754.497787] rcu: blocking rcu_node structures:
[ 9761.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]
Además, intenté monitorear topdurante la descompresión y justo antes de iniciar, veo kauditdun aumento de menos del 0% de CPU a 70% -100% de CPU:
top - 12:00:01 up 21 min, 1 user, load average: 1.34, 1.29, 0.98
top - 12:02:53 up 24 min, 2 users, load average: 2.80, 1.87, 1.25
Tasks: 168 total, 4 running, 95 sleeping, 0 stopped, 0 zombie
%Cpu(s): 31.8 us, 48.8 sy, 0.0 ni, 0.0 id, 19.3 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 8149152 total, 2436876 free, 958672 used, 4753604 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 6878804 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22 root 20 0 0 0 0 R 79.3 0.0 0:02.92 kauditd
299 root 20 0 1563540 153316 35416 S 73.4 1.9 1:40.58 ds_am
29619 root 20 0 11528 5252 2088 S 3.6 0.1 0:14.03 unzip
466 root 19 -1 144180 58788 57688 S 1.3 0.7 0:03.89 systemd-journal
21596 root 20 0 0 0 0 I 0.7 0.0 0:00.65 kworker/u4:1-ev
¿Qué podría estar causando que el demonio de auditoría del kernel ocupe tanta CPU de manera tan repentina? No fue un aumento gradual, sino un aumento hasta el 100% y luego una congelación de la VM.
¿Alguien encontró esto antes?
Respuesta1
No puedo decir por qué. Pero te sugiero que uses SCREEN o BYOB y descomprimas en segundo plano.
Mientras descomprime el archivo, simplemente cierra tu sesión SSH, regresa después de unos minutos y ¡VOILA!
Respuesta2
Creo que esto es causado por algún componente deTendencia Microsoftware. Su resultado principal muestra 1:40.58el tiempo dedicado a ds_am, una fracción significativa de su tiempo de actividad.
El software de ese tipo también es un candidato probable (aunque no el único) para configurar las funciones de auditoría del núcleo.
Consulte la documentación y/opóngase en contacto con el proveedor de softwaresobre el uso directo de recursos. Sin embargo, primero verifique si aún hay tareas pendientes de mantenimiento regular o actualización para ese software.
Determine la configuración del marco de auditoría del kernel e identifique otro software que interactúe con él. (intentar
auditctl)