Proprio di recente ho notato che la durata della batteria è in calo e il processo "kernel_task" utilizza un bel po 'di CPU (un 1-6% costante sul mio i7 dual-core i7, 2010 MBP). Ovviamente penso che l'utilizzo della CPU del kernel_task stia contribuendo alla caduta della batteria e ho bisogno di scoprire perché.

Cercando su Google, sembra che kernel_task sia la versione OS X di "svchost.exe" di Windows - il famigerato processo fai-da-te di cui non puoi mai veramente eseguire il debug, devi solo girare manualmente gli interruttori fino a quando uno di loro funziona.

Esiste un modo per raggiungere più facilmente il fondo dell'attività kernel_task fuori controllo? Non ho provato un riavvio perché se questo lo "risolve", in realtà non risolve il problema sottostante.

Activity Monitor mostra l'utilizzo della CPU. Quando premo Inspect, mostra 77 thread, 2 porte, ore e ore di tempo della CPU, Switch di contesto che salgono di circa 400 al secondo e Mach Messaggi In e Out che salgono a circa 6.000 al secondo.

Come posso in qualche modo ispezionare o monitorare questo kernel_taskprocesso e capire cosa sta effettivamente usando tutto questo potere?

_{(nota: i miei attuali sospettati sono il recente aggiornamento 10.6.7, l'aggiornamento di Firefox da 4 beta 10 a RC o ScreenResX - queste sono tutte cose che ho fatto di recente che mi viene in mente)}

Ho avuto una domanda simile su come identificare file e programmi collegati a kernal_task usando il seguente comando 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 grande 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 occupando memoria eseguendo il piping di cui sopra grep -v com.apple. È possibile che alcuni programmi non Apple stiano esaurendo le tue risorse. Dovresti essere in grado di rimuoverli senza rompere nulla.

Ovviamente la vecchia soluzione è riavviare il computer. A volte è tutto ciò che serve per riportare i processi ai loro normali livelli di utilizzo della CPU.

Ecco una grande spiegazione di cosa sia kernel_task. Potrebbe essere driver (kexts), attività di rete o disco. Non puoi semplicemente usare gli strumenti per collegarti al kernel_taskprocesso.

Cerca altri segni, come i log (Console.app), l'attività del disco (ad esempio:), l'attività di iotop fs_usagerete (prova a disconnetterti dalla rete locale, spegni i dispositivi nelle preferenze di rete), prova a disinstallare / rimuovere dalla memoria ( kextunload) i driver, che provengono da terze parti: tablet, modem USB 3G e così via. Verifica la presenza di applicazioni che installano kexts

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

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

Quindi una soluzione è raffreddare il tuo Mac (ad esempio una ventola) attraverso una ventola esterna o qualcosa come SMCFanControl .

L'articolo fornisce un'altra soluzione che consiste nel rimuovere il sottotitolo che attiva quel comportamento. Anche se devo ammettere che personalmente non sono sicuro di quanto sia sicuro disattivare quel comportamento.

Di solito kernel_taskè fuori controllo quando alcuni altri processi utilizzano in modo eccessivo chiamate di sistema o risorse (eventi di I / O di memoria o del disco).

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

Quindi esegui questo comando nel Terminale:

sudo fs_usage

quindi osserva quali processi eseguono spesso alcune chiamate di sistema e se non li stai utilizzando, considera di chiuderli / ucciderli.

Per essere più specifici, controlla la colonna INTERVALLO TEMPO che ti dà il tempo trascorso trascorso nella chiamata di sistema. Un tempo che Wappare dopo che è trascorso indica che il processo è stato pianificato per attività (in quel caso il tempo trascorso include il tempo di attesa).

Quindi, al fine di filtrare i processi che utilizzano il maggior intervallo di tempo nelle chiamate di sistema, eseguire:

sudo fs_usage | grep -v 0.0000

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

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

Ecco i problemi più comuni:

• VBoxHeadless: se stai usando VM (via vagrant), considera di sospenderle quando non sono in uso;
• mtmd: sembra che Time Machine esegua il backup dei dati ogni ora anche quando l'unità di backup non è connessa (le cosiddette snapshot locali ), quindi prova a disabilitarla ( sudo tmutil disablelocal);
• wine: se stai eseguendo app di Windows, considera di chiuderle quando non sono in uso;

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

  ^{Verifica: addon Chrome per interrompere il messaggio "Pagina / e non rispondente" .}

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

Ho avuto lo stesso problema in Yosemite ma grazie a questa buona anima basata su questo un altro bravo ragazzo ho potuto risolverlo. Non riesco ancora a capire cosa sia successo, ma dopo aver perso un intero fine settimana cercando di risolverlo ho appena rinunciato e seguo ciecamente le sue istruzioni. Guarda la mia disperazione nel monitor delle attività:

Fare attenzione, eseguire sempre prima un backup e leggere i collegamenti forniti per una spiegazione. Non mi assumo alcuna responsabilità per eventuali danni causati. Sei stato avvisato.

Trova il modello

$ system_profiler -detailLevel mini | grep "Identificatore modello:"

Identificatore modello: MacBookPro8,2

Sposta e fai il backup del 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 2011 e di recente ho avuto kernel_task con circa il 25-30% della CPU e la mia ventola gira al massimo per ore e ore. Ho provato una cosa alla volta e ciò che è stato risolto è stato ... la chiusura di 5 o 6 finestre nell'app Finder. Non posso dire di aver capito perché, ma era chiaramente quello.

Sul mio Mac l'utilizzo della CPU di kernel_task è proporzionale alla larghezza di banda di Internet che utilizzo, compresa tra circa lo 0% e il 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: è sicuro spostare i bundle di kext da / Sistema / Libreria / Estensioni / in un'altra cartella e riavviare. Puoi usare Canary del consulente o kextstat | grep -v com.appleelencare le estensioni del kernel che non sono state fornite con OS X.

Per risolvere specificatamente kernel_task fuori controllo , ecco alcuni comandi utili:

• Profili l'intero sistema, concentrandosi sul processo del kernel (PID: 0), esegui:

  sudo spindump 0 -reveal
  

  Per processi specifici (come launchd), utilizzare sample, ad esempio sudo sample launchdo tramite PID.

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

  sudo footprint 0
  

  ^{Nota: utilizzare -aper indirizzare tutti i processi.}

• Per raccogliere le informazioni di diagnostica a livello di sistema da più utils, eseguire: sudo sysdiagnose.

  Questo può essere attivato anche premendo Shift- Control- ⌥- ⌘-. (punto).

  Dovresti vedere lo schermo lampeggiare quando avviato, quindi attendere alcuni minuti fino a quando il file non viene rivelato nel Finder .

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

  Poi decomprimere e controllare i file come footprint*.txt, spindump.txt, taskinfo.txt, bc_stats.txte altri.

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

  Fondamentalmente, più swap usi (controlla i file di swap in /private/var/vmcui sono gestiti da dynamic_pager, vedi :)man dynamic_pager , più il kernel sta lottando con le prestazioni a causa delle operazioni di Swapins / Swapouts (vedi man vm_state man fs_usage). Per testare, esegui:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Nota: premere Control- Cper interrompere.}

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

È anche sospetto che i "menumetri" riportino molto tempo "sys", per CPU. Puoi vederlo anche nel comando "top", ad esempioCPU usage: 21.40% user, 23.74% sys

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

sudo fs_usage ha mostrato molto di questo:

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

La mia teoria è che netbeans "leggesse così tanto" da causare persino agli errori di pagina l'esecuzione del proprio programma (ovvero l'invio per scambiare il proprio programma), ottenendo così una coda dietro il sistema di errore della pagina. E probabilmente anche lo scambio di "altri programmi" con lo swap, facendo rallentare l'intero sistema.

Usando top, anche la colonna GUASTO stava aumentando di 70K / sec.

Il mio macbook Pro era quasi inutilizzabile a causa dell'alta CPU kernel_task per settimane Allo stesso tempo la batteria si gonfiava quindi alla fine ho deciso di andare su Apple Center a Roma per sostituirlo ... anche se fuori garanzia Apple ha sostituito la mia batteria (e anche la tastiera) per un costo di 0 €. Ancora meglio ... il problema kernel_task scompare improvvisamente !!! quindi sono abbastanza sicuro che fosse a causa della batteria, direttamente o indirettamente