El viernes pasado actualicé mi servidor Ubuntu a 11.10, que ahora se ejecuta con un núcleo de servidor 3.0.0-12. Desde entonces, el rendimiento general se ha reducido drásticamente. Antes de la actualización, la carga del sistema era de aproximadamente 0.3, pero actualmente es de 22-30 en un sistema de CPU de 8 núcleos con 16 GB de RAM (10 GB gratis, sin intercambio).
Iba a culpar al controlador del sistema de archivos BTRFS y a la matriz MD subyacente, porque [md1_raid1] y [btrfs-transacti] consumían muchos recursos. Pero todos los [kworker / *: *] consumen mucho más.
sar ha producido algo similar a esto constantemente desde el viernes:
11:25:01 CPU %user %nice %system %iowait %steal %idle
11:35:01 all 1,55 0,00 70,98 8,99 0,00 18,48
11:45:01 all 1,51 0,00 68,29 10,67 0,00 19,53
11:55:01 all 1,40 0,00 65,52 13,53 0,00 19,55
12:05:01 all 0,95 0,00 66,23 10,73 0,00 22,10
Y iostatconfirma una tasa de escritura muy pobre:
sda 129,26 3059,12 614,31 258226022 51855269
sdb 98,78 24,28 3495,05 2049471 295023077
md1 191,96 202,63 611,95 17104003 51656068
md0 0,01 0,02 0,00 1980 109
La pregunta es: ¿cómo puedo rastrear por qué los hilos de kworker consumen tantos recursos (y cuál)? O mejor: ¿Es un problema conocido con el kernel 3.0 y puedo modificarlo con los parámetros del kernel?
Editar:
Actualicé el Kernel a la nueva versión 3.1 según lo recomendado por los desarrolladores de BTRFS. Pero desafortunadamente esto no cambió nada.
fuente
pcie_ports=compatopcie_ports=native. (Pruebe 'nativo' primero. Es menos probable que solucione el problema, pero es menos probable que cause otros problemas.)Respuestas:
Encontré este hilo en lkml que responde un poco a su pregunta. (Parece que incluso el propio Linus estaba desconcertado sobre cómo averiguar el origen de esos hilos).
Básicamente, hay dos formas de hacerlo:
Para esto, necesitará compilar ftrace en su kernel y habilitarlo con:
En la documentación de ftrace.txt se encuentra disponible más información sobre las funciones del trazador de funciones de Linux .
Esto generará lo que todos los hilos están haciendo y es útil para rastrear múltiples trabajos pequeños.
Esto generará la pila de un solo hilo haciendo mucho trabajo. Puede permitirle descubrir qué causó que este hilo específico acaparara la CPU (por ejemplo).
THE_OFFENDING_KWORKERes el pid del kworker en la lista de procesos.fuente
-Eopción de dormir, ¡y el uso de la CPU desapareció!La solución es: no sé cómo encontrar la causa. Nadie me lo dijo hasta ahora.
Pero hablar con los desarrolladores de BTRFS reveló un error en los controladores btrfs al escribir muchos archivos pequeños en un período de tiempo muy corto. Este es un problema en los núcleos desde 3.0 hasta 3.1. Tal vez se arregla en 3.2.
Mientras tanto, recibí un parche para el núcleo actual que resolvió el problema.
fuente
Tuve un problema similar; mirando la pila de hilos de kworker:
Supuse que eran los módulos usb. Anteriormente, en otra máquina, tenía todos los módulos usb y [uex] hci conscientes de que había apagado el teclado (¡ni siquiera ctrl-shift-sysrq-U!), Así que terminé haciendo esto:
Hizo el truco:
Entonces, mi principal sospechoso es este gadget: RTL8723B * WIFI + Módulo Bluetooth. Ahora me pregunto si el código de administración de energía se da cuenta de que es el mismo dispositivo si intenta, por ejemplo, apagar un adaptador BT no utilizado.
contexto:
fuente
echo N >/sys/module/drm_kms_helper/parameters/poll(en modo raíz)Problema con la tarjeta gráfica Intel
fuente