Recientemente, noté que la duración de la batería tenía una caída bastante significativa y el proceso "kernel_task" con bastante CPU (un constante 1-6% en mi 2.8ghz dual-core i7, 2010 MBP). Obviamente, creo que el uso de CPU de kernel_task está contribuyendo a la caída de la batería y necesito averiguar por qué.

Al buscar en Google, parece que kernel_task es la versión de OS X de "svchost.exe" de Windows, el notorio proceso de hacer todo que nunca puede depurar realmente, solo tiene que activar manualmente los interruptores hasta que uno de ellos funcione.

¿Hay alguna forma en que pueda llegar más fácilmente al fondo de la actividad fuera de control kernel_task? No he intentado reiniciar porque si eso lo "arregla", realmente no soluciona el problema subyacente.

El Monitor de actividad muestra el uso de la CPU. Cuando presiono Inspeccionar, muestra 77 subprocesos, 2 puertos, horas y horas de tiempo de CPU, los interruptores de contexto suben aproximadamente 400 por segundo y los mensajes de entrada y salida de Mach suben a aproximadamente 6,000 por segundo.

¿Cómo puedo inspeccionar o monitorear de alguna manera este kernel_taskproceso y descubrir qué está usando realmente todo este poder?

_{(nota: mis sospechosos actuales son la reciente actualización 10.6.7, la actualización de Firefox de 4 beta 10 a RC, o ScreenResX; estas son todas las cosas que he hecho recientemente que puedo pensar)}

Tuve una pregunta similar sobre cómo identificar archivos y programas conectados a kernal_task usando el siguiente comando de terminal:

kextstat -l -k | awk '{n = sprintf("%d", $4); print n, $6}' | sort -n

Esto mostrará varios kexts y la memoria asociada a ellos. Por ejemplo, 6184960 com.apple.driver.AirPort.Brcm4360es un gran cerdo para mí, pero no puedo hacer mucho al respecto si quiero usar wifi.

Una de las sugerencias que recibí fue buscar todos los kexts que no son de Apple que están ocupando memoria conectando lo anterior a grep -v com.apple. Es posible que algunos programas que no sean de Apple estén utilizando sus recursos. Debería poder eliminarlos sin romper nada.

La solución antigua, por supuesto, es reiniciar su computadora. A veces, eso es todo lo que se necesita para restablecer los procesos a sus niveles normales de uso de CPU.

Aquí hay una gran explicación de qué es una kernel_task. Podrían ser controladores (kexts), red o actividad de disco. No puede simplemente utilizar instrumentos para adjuntar al kernel_taskproceso.

Busque otros signos, como registros (Console.app), actividad de disco (por ejemplo:), actividad de iotop fs_usagered (intente desconectarse de la red local, apague los dispositivos en las preferencias de red), intente desinstalar / eliminar de la memoria ( kextunload) controladores, que son de terceros: tabletas, módems usb 3g, etc. Verifique las aplicaciones que están instalando kexts

También asegúrese de que su sistema de archivos no esté dañado, si tuvo algún bloqueo recientemente, realice una comprobación.

Como mencionó @Christopher, el calor puede hacer que la CPU kernel_task se dispare. El motivo se enumera en esta publicación "Arreglando" los problemas de CPU kernel_task en MacOS Lion 10.7 . Aparentemente, cuando la CPU se calienta, el ACPI_SMC_PlatformPlugin.kext tomará ciclos de la CPU en un intento de reducir la carga real de la CPU.

Entonces, una solución es enfriar su Mac (por ejemplo, un ventilador) a través de un ventilador externo o algo así como SMCFanControl .

El artículo da otra solución que es eliminar el sub-kext que desencadena ese comportamiento. Aunque debo admitir que personalmente no estoy seguro de cuán seguro es desactivar ese comportamiento.

Por kernel_tasklo general, está fuera de control cuando algunos otros procesos utilizan en exceso las llamadas o recursos del sistema (eventos de memoria o de E / S de disco).

Cuando esto sucede, puede usar la fs_usageutilidad de informes que le mostrará las llamadas al sistema y los fallos de página relacionados con la actividad del sistema de archivos en tiempo real.

Entonces ejecute este comando en la Terminal:

sudo fs_usage

luego observe qué procesos realizan con frecuencia algunas llamadas al sistema y, si no las está utilizando, considere cerrarlas / eliminarlas.

Para ser más específico, verifique la columna INTERVALO DE TIEMPO que le brinda el tiempo transcurrido en la llamada al sistema. Una Waparición después del tiempo transcurrido indica que el proceso se programó fuera de la actividad (en ese caso, el tiempo transcurrido incluye el tiempo de espera).

Entonces, para filtrar los procesos que utilizan el mayor intervalo de tiempo en las llamadas del sistema, ejecute:

sudo fs_usage | grep -v 0.0000

que le mostrará en la última columna los procesos más hambrientos (en términos de tiempo de kernel). Puede ajustar el número de ceros para mayor precisión (menos ceros mostrados, más tiempo invertido).

Para obtener más ideas, consulte también: ¿Cómo investigar el uso de memoria de tareas de alto kernel?

Estos son los problemas más comunes:

• VBoxHeadless: si está utilizando máquinas virtuales (a través de vagabundo), considere suspenderlas cuando no estén en uso;
• mtmd: parece que Time Machine realiza copias de seguridad de sus datos cada hora, incluso cuando su unidad de copia de seguridad no está conectada (las llamadas instantáneas locales ), por lo que intente deshabilitarla ( sudo tmutil disablelocal);
• wine: si está ejecutando aplicaciones de Windows, considere cerrarlas cuando no esté en uso;

• Chrome: limite el número de pestañas abiertas al mismo tiempo (pruebe OneTab y / o TGS ) o elimine algunos procesos de Extensión ( JavaScript ) a través del Administrador de tareas , ya que cada pestaña podría generar un proceso separado.

  ^{Marque: Complemento de Chrome para detener el mensaje "Página (s) que no responde" .}

Tuve un pico masivo en el uso de CPU kernel_task, y resultó que mi ventilador de CPU estaba parcialmente desconectado. kernel_task tiene algo que ver con la aceleración de la CPU cuando hace demasiado calor. En su caso, tal vez su ventilador esté lleno de basura y polvo y deba limpiarse.

Tuve el mismo problema en Yosemite pero gracias a esta buena alma basada en este otro buen compañero pude resolverlo. Todavía no puedo entender lo que pasó, pero después de perder todo un fin de semana tratando de resolverlo, me rendí y seguí ciegamente sus instrucciones. Mira mi desesperación en el monitor de actividad:

Tenga cuidado, siempre haga una copia de seguridad primero y lea los enlaces proporcionados para obtener una explicación. No asumo ninguna responsabilidad por los daños causados. Has sido advertido.

Encuentra el modelo

$ system_profiler -detailLevel mini | grep "Identificador del modelo:"

Identificador del modelo: MacBookPro8,2

Mover y respaldar el archivo

$ mkdir -p ~ / copia de seguridad

$ cd /System/Library/Extensions/IOPlatformPluginFamily.kext/Contents/PlugIns/ACPI_SMC_PlatformPlugin.kext/Contents/Resources

$ sudo mv MacBookPro8_2.plist ~ / backup /

Estoy en OSX Lion con un nuevo macbook pro 2011, y recientemente tuve kernel_task ejecutando alrededor del 25-30% de la CPU y mi ventilador giraba al máximo durante horas y horas. Intenté una cosa a la vez y lo que resolvió fue ... cerrar 5 o 6 ventanas en la aplicación Finder. No puedo decir que entiendo por qué, pero fue claramente eso.

En mi Mac, el uso de CPU de kernel_task es proporcional al ancho de banda de Internet que uso, que varía de aproximadamente 0% a 50%. Probablemente sea causado por los controladores para mi módem Huawei 3G (HuaweiDataCardDriver.kext).

Puede intentar deshabilitar las extensiones del kernel. No es necesario usar kextunload: es seguro mover los paquetes de kext desde / System / Library / Extensions / a otra carpeta y reiniciar. Puede usar Consultant's Canary o kextstat | grep -v com.applepara enumerar las extensiones de kernel que no vienen con OS X.

Para solucionar problemas fuera de control kernel_task específicamente, aquí hay algunos comandos útiles:

• Perfile todo el sistema, enfocándose en el proceso del kernel (PID: 0), ejecute:

  sudo spindump 0 -reveal
  

  Para un proceso específico (como launchd), use sample, por ejemplo, sudo sample launchdo por PID.

• Para recopilar el consumo de memoria por tarea de kernel, use (ordenado por sucio de forma predeterminada):

  sudo footprint 0
  

  ^{Nota: Use -apara apuntar a todos los procesos.}

• Para recopilar información de diagnóstico en todo el sistema desde múltiples utilidades, ejecute: sudo sysdiagnose.

  Esto también se puede activar presionando Shift- Control- ⌥- ⌘-. (punto).

  Debería ver que la pantalla parpadea cuando se inicia, luego espere unos minutos hasta que el archivo aparezca en Finder .

  ^{Consulte: ¿Cómo obtiene archivos de diagnóstico del sistema de OS X?}

  Luego descomprimir y comprobar los archivos tales como footprint*.txt, spindump.txt, taskinfo.txt, bc_stats.txty otros.

• Compruebe vm.swapusageen los estados del núcleo, por ejemplo sysctl -a | grep ^vm.swapusage.

  Básicamente, cuanto más intercambio use (verifique los archivos de intercambio en los /private/var/vmque está administrado dynamic_pager, vea :)man dynamic_pager , más kernel tendrá problemas con el rendimiento debido a las operaciones Swapins / Swapouts (vea man vm_staty man fs_usage). Para probar, ejecute:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Nota: Presiona Control- Cpara parar.}

Para mí, tuve un proceso (Netbeans en este caso, que estaba leyendo un archivo como 20GB) y usaría como 80% de CPU para netbeans, 20% de CPU para kernel_task (muy sospechoso). Esto hizo que todo mi sistema funcionara como alquitrán.

También es sospechoso que los "menumeters" reporten mucho tiempo "sys", por CPU. También puede ver esto en el comando "superior", comoCPU usage: 21.40% user, 23.74% sys

Más tarde, podría ser netbeans 120% cpu, kernel_task 65%, pero de todos modos ambos eran "high cpu al mismo tiempo"

sudo fs_usage mostró mucho de esto:

12:46:34.446367  PAGE_IN_FILE      A=0x093a5bb000       0.000001   java.453214

Mi teoría es que netbeans estaba "leyendo tanto" que estaba causando que las fallas de la página incluso ejecutaran su propio programa (es decir, enviando para intercambiar su propio programa), por lo que obtuvo una cola detrás del sistema de fallas de la página. Y probablemente intercambiando "otros programas" para que también se intercambien, haciendo que todo el sistema se desmorone.

Usando top, la columna FALLO también aumentaba en 70K / seg.

Mi MacBook Pro estuvo casi inutilizable debido a la alta CPU de kernel_task durante semanas. Al mismo tiempo, la batería se infló, así que finalmente decidí ir al Apple Center en Roma para reemplazarla ... incluso si fuera de garantía Apple reemplazó mi batería (y teclado también) por 0 € de coste. Aún mejor ... ¡el problema kernel_task desaparece de repente! así que estoy bastante seguro de que fue por la batería, directa o indirectamente