Tenía un 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 con ellos. Por ejemplo, 6184960 com.apple.driver.AirPort.Brcm4360 es un gran problema para mí, pero no puedo hacer mucho al respecto si quiero usar wifi.

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

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

Aquí hay una gran explicación que es un kernel_task Podría ser controladores (kexts), red o actividad de disco. No puede simplemente usar Instrumentos para adjuntar al proceso kernel_task .

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

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

Como lo mencionó @Christopher, el calor puede hacer que la CPU kernel_task aumente. El motivo se incluye en esta publicación "Solución de problemas de la CPU kernel_task en MacOS Lion 10.7 . Aparentemente, cuando la CPU se calienta, ACPI_SMC_PlatformPlugin.kext tomará ciclos de la CPU en un intento por 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 como SMCFanControl .

El artículo ofrece otra solución que consiste en eliminar el sub-kext que activa ese comportamiento. Aunque debo admitir que personalmente no estoy seguro de qué tan seguro es desactivar ese comportamiento.

Tuve un aumento masivo en el uso de la 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 simplemente esté atascado con basura y polvo y necesita ser limpiado.

Tuve el mismo problema en Yosemite pero gracias para esta buena alma basada en este otra buena compañera podría resolverlo. Todavía no puedo entender lo que sucedió, pero después de perder todo un fin de semana intentando resolverlo, simplemente me rendí y seguí ciegamente sus instrucciones. Mira mi desesperación en el monitor de actividad:

Tengacuidado,siemprehagaunacopiadeseguridadprimeroylealosenlacesproporcionadosparaobtenerunaexplicación.Noasumoningunaresponsabilidadporcualquierdañocausado.Hassidoadvertido.

  

Encuentraelmodelo

    

$system_profiler-detailLevelmini|grep"Identificador de modelo:"

     

Identificador de modelo: MacBookPro8,2

     

Mover y hacer una copia de seguridad del archivo

     

$ mkdir -p ~ / backup

     

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

     

$ sudo mv MacBookPro8_2.plist ~ / backup /

Por lo general, kernel_task está fuera de control cuando algunos otros procesos están sobreutilizando las llamadas o los recursos del sistema (eventos de memoria o E / S de disco).

Cuando esto sucede, puede usar la utilidad de informes fs_usage que le mostrará las llamadas al sistema y las fallas de página relacionadas con la actividad del sistema de archivos en tiempo real.

Ejecute este comando en la Terminal:

sudo fs_usage

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

Para ser más específico, verifique la columna INTERVALO DE HORA que le da el tiempo transcurrido en la llamada al sistema. Un W que aparece después del tiempo transcurrido indica que el proceso se programó como 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 núcleo). Puede ajustar la cantidad de ceros por precisión (menos ceros mostrados, más tiempo empleado).

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

Estos son los problemas más comunes:

• VBoxHeadless : si está utilizando máquinas virtuales (a través de vagrant), considere suspenderlas cuando no esté en uso;
• mtmd : parece Time Machine realiza copias de seguridad de sus datos cada hora, incluso cuando su copia de seguridad la unidad no está conectada (también llamada instantáneas locales ), así que intente deshabilitándolo ( sudo tmutil disablelocal );
• wine : si está ejecutando aplicaciones de Windows, considere cerrarlas cuando no esté en uso;

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

  ^{Marque: Complemento de Chrome para detener “Página ) No responde "mensaje .}

Estoy en OSX Lion con un nuevo macbook pro 2011, y hace poco tuve kernel_task ejecutando alrededor del 25-30% de la CPU y mi ventilador giró 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 era claramente eso.

En mi Mac, el uso de la CPU de kernel_task es proporcional al ancho de banda de Internet que utilizo, que oscila entre el 0% y el 50%. Probablemente es causado por los controladores para mi módem 3G de Huawei (HuaweiDataCardDriver.kext).

Podrías intentar deshabilitar las extensiones del kernel. No es necesario utilizar kextunload: es seguro mover los paquetes de kext de / System / Library / Extensions / a otra carpeta y reiniciar. Puede usar Canary del Consultor o kextstat | grep -v com.apple para enumerar las extensiones del 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, centrá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 launchd o por PID.

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

  sudo footprint 0
  

  ^{Nota: use -a para orientar todos los procesos.}

• Para recopilar información de diagnóstico de todo el sistema de varias utilidades, ejecute: sudo sysdiagnose .

  Esto también puede activarse presionando Mayús - Control - ⌥ - ⌘ - < kbd>. (período).

  Debería ver parpadear la pantalla cuando se inicia, luego esperar unos minutos hasta que el archivo se muestre en Finder .

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

  Luego descomprima y verifique los archivos como footprint*.txt , spindump.txt , taskinfo.txt , bc_stats.txt y otros.

• Ver vm.swapusage en los estados del kernel, por ejemplo. sysctl -a | grep ^vm.swapusage .

  Básicamente, más swap usas (verifica los archivos swap en /private/var/vm que son administrados por dynamic_pager , ver: man dynamic_pager ), más kernel lucha con el rendimiento debido a Swapins / Swapouts (consulte man vm_stat y man fs_usage ). Para probar, ejecute:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Nota: pulsa Control - C para detener.}

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

También es sospechoso que los "menumetros" reporten un montón de tiempo "sys", por cpu. También puedes ver esto en el comando "top", como CPU 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 "cpu alto 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 obtenemos una cola detrás del sistema de fallas de la página. Y probablemente cambiando "otros programas" para intercambiar también, haciendo que todo el sistema funcione.

Al utilizar top , la columna de FALLA también aumentó en 70 K / seg.