Una instalación nueva de ZimaOS que se mantiene cerca del 30 % de CPU durante muchas horas no debería descartarse automáticamente como «normal», especialmente cuando la lista de procesos muestra kworker. El siguiente paso útil es identificar qué trabajador del kernel está activo y qué dispositivo o interrupción lo mantiene ocupado.
En este hilo, se descartó AI Search y el usuario siguió observando el comportamiento después de unas diez horas. La baja temperatura y el consumo reducido eran tranquilizadores, pero no demostraban por qué los trabajadores del kernel estaban activos.
Lo que realmente mostró el hilo
El sistema original utilizaba un i3-6100T con dos núcleos y cuatro hilos. Una respuesta de la comunidad sugirió inicialmente que se trataba de actividad posterior a la instalación y consultas periódicas de la interfaz web, pero el usuario confirmó después que la carga persistió durante unas diez horas y que AI Search estaba desactivado.
Otra respuesta describió kworker como trabajo del kernel relacionado con controladores, interrupciones, gestión de energía, discos y redes. Esa descripción es, en líneas generales, correcta, pero el hilo no demostró que una carga del 25–30 % sea siempre inofensiva en una CPU de dos núcleos.
Identifica el trabajador ocupado antes de cambiar la configuración
Empieza por consultar la lista de procesos mientras el panel muestre el pico. Si un hilo kworker aumenta repetidamente al mismo tiempo, registra su nombre, porcentaje de CPU y la hora exacta. Después, comprueba si la actividad cambia al desconectar uno por uno los dispositivos USB opcionales, dejar inactivos los discos, desconectar las NIC adicionales u otro hardware.
El mismo principio aparece en la lista de comprobación de cuellos de botella de NAS: relaciona el síntoma con el recurso y el proceso que cambian en el mismo momento, en lugar de actualizar el hardware basándote en un solo gráfico.
Descarta el trabajo en segundo plano y los errores recientes
Las instalaciones nuevas pueden realizar tareas de detección, indexación e inicialización de servicios, por lo que un pico breve después del arranque no indica necesariamente un fallo. Sin embargo, que persista durante muchas horas cambia el diagnóstico. Cierra la interfaz web, detén las aplicaciones no esenciales, confirma el estado de AI Search y reinicia una vez para comprobar si vuelve a aparecer el mismo trabajador.
Compara también el comportamiento después de actualizar a la versión actual. Las notas de ZimaOS 1.7.1 incluyen correcciones de estabilidad y memoria, aunque no afirman específicamente solucionar este informe de kworker de febrero de 2026.
Cuándo escalar el problema
Escala el problema cuando un trabajador siga ocupado después de un reinicio limpio, aumenten la temperatura o el consumo, el sistema se vuelva lento o la carga cambie de forma predecible al conectar un dispositivo. Recopila la versión de ZimaOS, el modelo de hardware, la salida de top y el nombre exacto del trabajador.
Para conocer un método general que permita distinguir la presión de CPU de la presión de almacenamiento o de red, el método de análisis de cuellos de botella de recursos utiliza el mismo enfoque basado en evidencias.
En resumen
El hilo no demostró que un 30 % de CPU en reposo sea normal en todos los sistemas ZimaOS con pocos núcleos. Una temperatura y un consumo bajos son buenas señales, pero un uso persistente de kworker aún merece un aislamiento a nivel de proceso y de dispositivo antes de aceptarlo como inofensivo.
