Ho avuto un domanda simile su come identificare file e programmi collegati a kernal_task usando il seguente comando di terminale:

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

Questo mostrerà vari kexts e la memoria ad essi associata. Ad esempio, 6184960 com.apple.driver.AirPort.Brcm4360 è un grosso maiale per me, ma non posso farci molto se voglio usare il wifi.

Uno dei suggerimenti che ho ricevuto è stato quello di cercare tutti i kex non Apple che stanno recuperando memoria collegando il precedente a grep -v com.apple . È possibile che alcuni programmi non Apple stiano utilizzando le tue risorse. Dovresti essere in grado di rimuovere quelli senza rompere nulla.

Naturalmente la vecchia soluzione è riavviare il computer. A volte basta tutto per riportare i processi ai normali livelli di utilizzo della CPU.

Ecco una ottima spiegazione cos'è un kernel_task. Potrebbe essere i driver (kexts), la rete o l'attività del disco. Non puoi semplicemente usare Strumenti per collegarti al processo kernel_task .

Cerca altri segni, come i registri (Console.app), l'attività del disco (ad esempio: iotop fs_usage ), attività di rete (prova a disconnetterti dalla rete locale, spegnendo i dispositivi nelle preferenze di rete), prova a disinstallare / rimuovi dalla memoria ( kextunload ) i driver, che sono di terze parti - compresse, modem usb 3g e così via. Verifica le applicazioni che installano kex

Assicurati anche che il tuo file system non sia corrotto, se hai avuto qualche crash di recente - fai un controllo.

Come menzionato da @Christopher, heat può causare il picco della CPU kernel_task. Il motivo è elencato in questo post "Risoluzione" dei problemi della CPU kernel_task in MacOS Lion 10.7 . Apparentemente quando la CPU si surriscalda, ACPI_SMC_PlatformPlugin.kext eseguirà cicli di CPU nel tentativo di ridurre il carico effettivo della CPU.

Quindi una soluzione è quella di raffreddare il tuo Mac (ad esempio un fan) tramite un ventilatore esterno o qualcosa di simile a SMCFanControl .

L'articolo fornisce un'altra soluzione che è quella di rimuovere il sub-kext che attiva quel comportamento. Anche se devo ammettere che non sono personalmente sicuro di quanto sia sicuro disattivare quel comportamento.

Ho avuto un picco enorme nell'uso della CPU kernel_task, e ho scoperto che la mia ventola della CPU era parzialmente scollegata. kernel_task ha qualcosa a che fare con la limitazione della CPU quando fa troppo caldo. Nel tuo caso, forse il tuo fan è solo gommato con spazzatura e polvere e deve essere ripulito.

Di solito kernel_task è fuori controllo quando alcuni altri processi stanno sfruttando eccessivamente le chiamate di sistema o le risorse (eventi di I / O su memoria o disco).

Quando ciò accade, puoi utilizzare l'utilità di reporting fs_usage che ti mostrerà le chiamate di sistema e gli errori di pagina relativi all'attività del filesystem in tempo reale.

Quindi esegui questo comando in Terminale:

sudo fs_usage

quindi osserva quali processi eseguono frequentemente alcune chiamate di sistema e se non le stai utilizzando, prendi in considerazione la possibilità di chiuderle / ucciderle.

Per essere più specifici, controlla la colonna INTERVALLO TEMPO che ti dà il tempo trascorso trascorso nella chiamata di sistema. Un W visualizzato dopo il tempo trascorso indica che l'attività è stata programmata (in questo caso il tempo trascorso include il tempo di attesa).

Quindi per filtrare i processi che utilizzano il maggior intervallo di tempo nelle chiamate di sistema, esegui:

sudo fs_usage | grep -v 0.0000

che mostrerà nell'ultima colonna i processi più affamati (in termini di tempo del kernel). Puoi regolare il numero di zeri per la precisione (meno zeri visualizzati, più tempo speso).

Per ulteriori idee, controlla anche: Come analizzare l'utilizzo elevato della memoria delle attività del kernel?

Ecco i problemi più comuni:

• VBoxHeadless : se usi VM (tramite vagabondo), considera di sospenderli quando non sono in uso;
• mtmd : sembra Time Machine esegue il backup dei dati ogni ora anche quando il backup drive non è connesso (così chiamato snapshot locali ), quindi prova disabilitandolo ( sudo tmutil disablelocal );
• wine : se stai utilizzando le app di Windows, considera di chiuderle quando non sono in uso;

• Chrome : limite del numero di schede aperte contemporaneamente (prova OneTab e / o TGS ) o uccidi alcuni processi di estensione ( JavaScript ) tramite Task Manager , poiché ogni scheda potrebbe generare un processo separato.

  ^{Verifica: Chrome addon per fermare "Pagina (s Messaggio "non risponde" .}

Ho avuto lo stesso problema in Yosemite ma grazie a questa buona anima basata su questo altro buon compagno potrei risolverlo. Non riesco ancora a capire cosa sia successo, ma dopo aver perso un intero weekend cercando di risolverlo ho semplicemente rinunciato e seguo ciecamente le sue istruzioni. Guarda la mia disperazione nel monitoraggio dell'attività:

Faiattenzione,eseguisempreunbackupeleggiicollegamentifornitiperspiegazioni.Prendolaresponsabilitàzeroperqualsiasidannocausato.Seistatoavvisato.

Findthemodel

$system_profiler-detailLevelmini|grep"Model Identifier:"

Model Identifier: MacBookPro8,2

Move and backup the file

$ mkdir -p ~/backup

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

$ sudo mv MacBookPro8_2.plist ~/backup/

Sono su OSX Lion con un nuovo macbook pro del 2011, e di recente ho avuto kernel_task con circa il 25-30% della CPU e il mio fan girava al massimo per ore e ore. Ho provato una cosa alla volta e quello che ha risolto è stato ... chiudere 5 o 6 finestre nell'app Finder. Non posso dire di aver capito perché, ma era chiaramente questo.

Sul mio Mac l'uso della CPU di kernel_task è proporzionale alla larghezza di banda internet che uso, che va da circa lo 0% al 50%. Probabilmente è causato dai driver per il mio modem Huawei 3G (HuaweiDataCardDriver.kext).

Potresti provare a disabilitare le estensioni del kernel. Non è necessario utilizzare kextunload: è sufficiente spostare i pacchetti kext da / System / Library / Extensions / a un'altra cartella e riavviare. Puoi utilizzare il consulente di Canary o kextstat | grep -v com.apple per elencare le estensioni del kernel che non sono state fornite con OS X.

Per risolvere in modo specifico kernel_task fuori controllo, ecco alcuni comandi utili:

• Esegui il profile dell'intero sistema, concentrandoti sul processo del kernel (PID: 0), esegui:

  sudo spindump 0 -reveal
  

  Per un processo specifico (come launchd ), usa sample , ad es. sudo sample launchd o PID.

• Per raccogliere il consumo di memoria in base all'attività del kernel, utilizzare (ordinato per impostazione predefinita per impostazione predefinita):

  sudo footprint 0
  

  ^{Nota: utilizza -a per indirizzare tutti i processi.}

• Per raccogliere informazioni diagnostiche a livello di sistema da più utilità, esegui: sudo sysdiagnose .

  Questo può anche essere attivato premendo Maiusc - Controllo - ⌥ - ⌘ - < kbd>. (punto).

  Dovresti vedere lo schermo lampeggiare quando viene avviato, quindi attendere alcuni minuti finché il file non viene rivelato in Finder .

  ^{Vedi: Come si ottengono i file di diagnostica del sistema da OS X?}

  Quindi decomprimi e controlla i file come footprint*.txt , spindump.txt , taskinfo.txt , bc_stats.txt e altro.

• Controlla vm.swapusage negli stati del kernel, ad es. sysctl -a | grep ^vm.swapusage .

  In sostanza, più swap che usi (controlla i file di swap in /private/var/vm che sono gestiti da dynamic_pager , vedi: man dynamic_pager ), più kernel sta lottando con le prestazioni a causa di Swapins / Operazioni di swapout (vedere man vm_stat e man fs_usage ). Per testare, esegui:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Nota: premi Control - C per fermare.}

Per me ho avuto un processo (Netbeans in questo caso, che stava leggendo un file come 20GB) e userebbe come 80% CPU per netbeans, 20% CPU per kernel_task (molto sospetto). Ciò ha causato il funzionamento dell'intero sistema come tar.

Inoltre, è sospetto che i "menumetri" riportino un sacco di tempo "sys", per CPU. Puoi vederlo anche nel comando "top", come CPU usage: 21.40% user, 23.74% sys

Più tardi, potrebbe essere netbeans 120% cpu, kernel_task 65%, ma comunque erano entrambi "CPU alta allo stesso tempo"

sudo fs_usage ha mostrato molto:

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

La mia teoria è che netbeans stava "leggendo così tanto" che stava facendo sì che gli errori di pagina eseguissero anche il proprio programma (cioè l'invio per scambiare il proprio programma), ottenendo così una coda dietro il sistema di errore della pagina. E probabilmente scambiando "altri programmi" con lo swap, facendo sì che l'intero sistema si sparga.

Usando top , anche la colonna FAULT è aumentata di 70K / sec.