Apple tiene un artículo en su base de datos y conocimientos que explica[note]Muy por encima, la verdad[/note] el funcionamiento de kernel_task. Voy a intentar explicar de forma más amplia por qué kernel_task se dispara en consumo de recursos y cuales son los culpables[note]Posibles culpables[/note] de este problema.
El artículo de Apple indica:
Una de las funciones del proceso kernel_task es ayudar a controlar la temperatura de la CPU. En el Monitor de actividad, se puede indicar que un proceso del sistema denominado kernel_task usa un alto porcentaje de la CPU, y, durante ese tiempo, es posible que notes mucha actividad del ventilador. Una de las funciones del proceso kernel_task es ayudar a controlar la temperatura de la CPU. Para ello, hará que la CPU esté menos disponible para los procesos que la usan de forma intensa. En otras palabras, el proceso kernel_task responde a las condiciones que provocan que la CPU se caliente demasiado, aunque no te parezca que la Mac está caliente. Sin embargo, no es la causa de esas condiciones. Cuando baja la temperatura de la CPU, kernel_task reduce automáticamente su actividad.Apple
En realidad, kernel_task no es el culpable, es la solución. Cuando tenemos este problema no debemos mirar a este proceso, sino qué será culpable de que el proceso se dispare en consumo de recursos.
Tanto en propio kernel con sus extensiones instaladas por Apple como las extensiones de kernel que pueden ser instaladas por otras aplicaciones tienen un comportamiento a la hora del consumo de recursos que no puede ser equilibrado por Apple a la hora de crear el proceso. Explicado para humanos, Apple no impide que el kernel o una extensión de kernel se ajuste a una serie de recursos específicos de salida, es decir, si desarrollas unos drivers especiales, el desarrollador no está obligado a capar la extensión de kernel a un uso limitado de recursos de, por ejemplo, el 50% del sistema. La extensión de kernel asumirá que puede utilizar tantos recursos como haya disponibles para poder ejecutarse. Esto ocurre tanto con el kernel como con todas las extensiones de kernel. Sin embargo, para limitar el uso de recursos, Apple utiliza este proceso que equivale a un semáforo que limita el uso de recursos a los disponibles y no más, y la razón de esa limitación de recursos es, tal como explica en su artículo, ayudar a controlar la temperatura de la CPU debido a que esos procesos intentan utilizar tantos recursos como puedan. Si lo miramos desde una perspectiva física, llegados a cierto límite de recursos disponibles en el ordenador, si un proceso actúa sobre el procesador con una fuerza (acción), el sistema reacciona contra aquél con otra fuerza de igual valor y dirección, pero de sentido contrario (reacción). [note]kernel_task[/note]. Por eso kernel_task consume tantos recursos, porque realmente está intentando parar a otro proceso que quiere consumir todos los recursos disponibles del ordenador.
¿Por qué pasa esto? Ahora que sabemos dónde tenemos que mirar, y no es a kernel_task, nos podemos hacer una idea de cómo solucionar estos problemas. Al final no se trata de intentar “bajar” kernel_task sino de encontrar el proceso que está consiguiendo que se dispare.
Lo más lógico sería, en un entorno de prueba y error, matar el proceso kernel_task y observar en el Monitor de Actividad qué proceso se dispara para tener una idea clara de por dónde van los tiros pero esto no es posible porque kernel_task pertenece a root y como usuario[note]Incluso administrador[/note] no puedes matarlo, pero no vamos a desanimarnos por esto.
Cuando kernel_task se dispara es porque un proceso asociado al kernel se dispara. Estos procesos pueden ser muy variados, pero en la mayoría de los casos se trata de:
- Un problema de periféricos conectados al Mac: es frecuente escuchar que si se desconecta tal o cual periférico, kernel_task vuelve a bajar su consumo de recursos. ya tenemos una idea de por qué sube: realmente el proceso asociado a ese periférico[note]Una unidad de almacenamiento, un monitor externo, los drivers de un dispositivo[/note] no está funcionando bien porque hay un problema de comunicación con ese dispositivo o porque el kernel del sistema o una de sus extensiones, incluidas las extensiones que haya podido instalar una aplicación están causando el problema, incluyendo la posibilidad de que dos extensiones de kernel, una del sistema y otra instalada por los drivers de una aplicación entren en conflicto.
- Un problema de drivers de software: por ejemplo, acceso a sistema de archivos no soportados directamente por el sistema o en general al uso de estándares de software. Por ejemplo, si instalamos un software que nos permite ver un tipo determinado de códec de vídeo no soportado directamente por el sistema a través de QuickTime, es posible que nos encontremos que el instalador, para que ese formato de vídeo esté disponible para todas las aplicaciones, haya instalado una extensión de kernel de forma que parezca de nítidamente el códec de vídeo está soportado a lo largo de todas las aplicaciones del sistema.
En general, este problema suele venir ocasionado por:
- Drivers para periféricos que instalamos en su momento y que quedaron atrás cuando dejamos de usar ese dispositivo.
- Drivers de software no actualizados que entran en conflicto directo con el sistema.
- El propio dispositivo que no soporta un estándar correctamente[note]O al revés, el sistema están intentando interpretar el estándar de forma que el periférico no acaba de entender[/note] o los cables asociados al mismo. Lo de los cables es importante: un mal cable puede estropearte el día.
En muchos casos, en la mayoría de ellos, los problemas de kernel_task están asociados a I/O Kit. I/O Kit es una colección de frameworks del sistema, bibliotecas, herramientas y otros recursos para crear drivers para dispositivos en OS X y macOS. Se basa en un modelo de programación orientado a objetos implementado en una forma restringida de C++ que omite características no aptas para su uso dentro de un núcleo multihilo. Mediante el modelado del hardware conectado a un sistema OS X/macOS y la abstracción de funciones comunes para dispositivos en determinadas categorías, i/O Kit agiliza el proceso de desarrollo de los drivers para un dispositivo – Apple. Aunque no seas desarrollador, es interesante echar un vistazo a la documentación de I/O Kit para entender cómo funciona y para qué sirve.
También es posible que el problema con el kernel y sus extensiones sea debido a la caché. Cuando macOS arranca, guarda una caché de las extensiones de kernel disponibles para poder arrancar más rápidamente la próxima vez. Si esa caché tiene problemas, es posible que kernel_task se dispare. Para reconstruir la caché de kernel en macOS Sierra y macOS 10.13 High Sierra:
- Abre el Terminal
- Introduce el comando
sudo kextcache -i /
- Se te solicitará la contraseña del administrador[note]Estamos usando sudo[/note]
- Una vez terminado el proceso, reinicia el Mac. Le llevará cierto tiempo reiniciar, puesto que tiene que reconstruir esa caché de nuevo.
Observa el comportamiento de kernel_task. Si todo ha vuelto a la normalidad, ya sabes que el problema era la caché.
Pues hace poco me sucedió algo extraño. Os lo cuento: estuve una estancia larga fuera de casa y me llevé el iMac de viaje conmigo, mientras duró el viaje, el ordenador se comportó como siempre, pero al llegar al llegar de nuevo a mi casa, de la noche a la mañana el ordenador no iba ni a patadas, super lento, con los ventiladores a tope y el proceso kernel_task se comía el 100% de la CPU. Contacte con el servicio técnico, hice un Apple hardware test (me dio todo ok), pensé desmontarlo por mí mismo, etc. pero al final, ¿sabéis cómo lo arreglé? Recordando el camino de vuelta en el coche tomé un bache bastante fuerte y pensé que a lo mejor podría arreglarlo haciendo el mismo proceso, a golpes XD , así que le di un golpe fuerte y seco desde arriba y supongo que el sensor de temperatura se volvió a colocar en su sitio y desde ese día me funciona de maravilla. Yahooooo!
PD: conste que no era mi intención hacer apología del maltrato a las máquinas. ?
Curioso.