Recentemente, notei que minha vida útil da bateria teve uma queda bastante significativa e o processo "kernel_task" usando bastante CPU (uma constante de 1 a 6% no meu 2.8GHz dual-core i7, 2010 MBP). Obviamente, acho que o uso da CPU do kernel_task está contribuindo para a queda da bateria e preciso descobrir o porquê.

Pesquisando no Google, parece que o kernel_task é a versão do OS X do "svchost.exe" do Windows - o notório processo de fazer tudo que você nunca consegue depurar de verdade, basta alternar manualmente os interruptores até que um deles funcione.

Existe alguma maneira de chegar mais facilmente à parte inferior da atividade kernel_task fora de controle? Não tentei reiniciar porque, se isso "corrige", realmente não corrige o problema subjacente.

O Activity Monitor mostra o uso da CPU. Quando acerto o Inspecionar, ele mostra 77 threads, 2 portas, horas e horas de tempo de CPU, os comutadores de contexto subindo cerca de 400 por segundo e o Mach Messages In and Out subindo cerca de 6.000 por segundo.

Como posso, de alguma forma, inspecionar ou monitorar esse kernel_taskprocesso e descobrir o que realmente está usando todo esse poder?

_{(nota: meus suspeitos atuais são a atualização 10.6.7 recente, a atualização do Firefox de 4 beta 10 para RC ou ScreenResX - são todas as coisas que fiz recentemente que consigo pensar)}

Eu tinha uma pergunta semelhante sobre como identificar arquivos e programas conectados ao kernal_task usando o seguinte comando terminal:

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

Isso exibirá vários kexts e a memória associada a eles. Por exemplo, 6184960 com.apple.driver.AirPort.Brcm4360é um grande porco para mim, mas não posso fazer muito se quiser usar o wifi.

Uma das sugestões que recebi foi procurar todos os kexts que não são da Apple estão ocupando memória, canalizando o acima para grep -v com.apple. É possível que alguns programas que não sejam da Apple estejam usando seus recursos. Você deve poder removê-los sem quebrar nada.

A solução antiga é claro, é reiniciar o computador. Às vezes, isso é o suficiente para restaurar os processos aos níveis normais de uso da CPU.

Aqui está uma ótima explicação do que é um kernel_task. Pode ser drivers (kexts), atividade de rede ou disco. Você não pode simplesmente usar instrumentos para se conectar ao kernel_taskprocesso.

Procure outros sinais, como logs (Console.app), atividade de disco (por exemplo:), atividade de iotop fs_usagerede (tente desconectar-se da rede local, desativar dispositivos nas preferências de rede), tente desinstalar / remover da memória ( kextunload) drivers, que são de terceiros - tablets, modems USB 3G e etc. Verifique se há aplicativos que estão instalando o kexts

Verifique também se o seu sistema de arquivos não está corrompido, se você teve alguma falha recentemente - verifique.

Conforme mencionado por @Christopher, o calor pode fazer com que a CPU kernel_task atinja o pico. O motivo está listado neste post "Corrigindo" problemas de CPU do kernel_task no MacOS Lion 10.7 . Aparentemente, quando a CPU aquece, o ACPI_SMC_PlatformPlugin.kext inicia os ciclos da CPU na tentativa de reduzir a carga real da CPU.

Portanto, uma solução é esfriar o seu Mac (por exemplo, ventilador) através de um ventilador externo ou algo como o SMCFanControl .

O artigo fornece outra solução, que é remover o subtexto que aciona esse comportamento. Embora eu deva admitir que, pessoalmente, não tenho certeza de como é seguro desativar esse comportamento.

Normalmente kernel_taskestá fora de controle quando alguns outros processos são o uso excessivo chamadas ou recursos (eventos de memória ou disco I / O) do sistema.

Quando isso acontece, você pode usar o fs_usageutilitário de relatórios, que mostrará as chamadas do sistema e falhas de página relacionadas à atividade do sistema de arquivos em tempo real.

Então, execute este comando no Terminal:

sudo fs_usage

observe quais processos estão frequentemente fazendo algumas chamadas do sistema e, se você não os estiver usando, considere fechá-los / eliminá-los.

Para ser mais específico, verifique a coluna INTERVALO DE TEMPO , que fornece o tempo decorrido gasto na chamada do sistema. Um Wtempo decorrido após a exibição indica que o processo foi agendado como atividade (nesse caso, o tempo decorrido inclui o tempo de espera).

Portanto, para filtrar os processos que estão usando o maior intervalo de tempo nas chamadas do sistema, execute:

sudo fs_usage | grep -v 0.0000

que mostrará na última coluna os processos mais famintos (em termos de tempo do kernel). Você pode ajustar o número de zeros para precisão (menos zeros exibidos, mais tempo gasto).

Para mais idéias, verifique também: Como investigar o alto uso de memória de tarefas do kernel?

Aqui estão os problemas mais comuns:

• VBoxHeadless: se você estiver usando VMs (via vagrant), considere suspendê-las quando não estiver em uso;
• mtmd: parece que o Time Machine faz backup dos dados a cada hora, mesmo quando sua unidade de backup não está conectada (os chamados instantâneos locais ), então tente desativá-los ( sudo tmutil disablelocal);
• wine: se você estiver executando aplicativos do Windows, considere fechá-los quando não estiver em uso;

• Chrome: limite o número de guias abertas ao mesmo tempo (tente OneTab e / ou TGS ) ou elimine alguns processos de extensão ( JavaScript ) por meio do Gerenciador de tarefas , pois cada guia pode gerar um processo separado.

  ^{Verifique: complemento do Chrome para interromper a mensagem "Página (s) que não responde" .}

Eu tive um pico enorme no uso da CPU kernel_task, e acabou que meu ventilador da CPU estava parcialmente desconectado. O kernel_task tem algo a ver com a otimização da CPU quando esta fica muito quente. No seu caso, talvez o seu ventilador esteja apenas cheio de lixo e poeira e precise ser limpo.

Eu tive o mesmo problema em Yosemite, mas graças a essa boa alma baseada nesse outro bom amigo, eu pude resolvê-lo. Ainda não consigo entender o que aconteceu, mas depois de perder um fim de semana inteiro tentando resolvê-lo, desisti e segui cegamente as instruções dele. Veja o meu desespero no monitor de atividades:

Tenha cuidado, sempre faça um backup primeiro e leia os links fornecidos para obter uma explicação. Eu assumo responsabilidade zero por qualquer dano causado. Voce foi avisado.

Encontre o modelo

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

Identificador do modelo: MacBookPro8,2

Mover e fazer backup do arquivo

$ mkdir -p ~ / backup

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

$ sudo mv MacBookPro8_2.plist ~ / backup /

Estou no OSX Lion com um novo macbook pro 2011 e recentemente tive o kernel_task executando cerca de 25 a 30% da CPU e meu ventilador girando no máximo por horas e horas. Tentei uma coisa de cada vez e o que resolveu foi ... fechar 5 ou 6 janelas no aplicativo Finder. Não posso dizer que entendo o porquê, mas era claramente isso.

No meu Mac, o uso de kernel_task na CPU é proporcional à largura de banda da Internet que eu uso, variando de 0% a 50%. Provavelmente, é causada pelos drivers do meu modem Huawei 3G (HuaweiDataCardDriver.kext).

Você pode tentar desativar as extensões do kernel. Não é necessário usar o kextunload: é seguro mover os pacotes do kext de / System / Library / Extensions / para outra pasta e reiniciar. Você pode usar o Canary do consultor ou kextstat | grep -v com.applelistar as extensões do kernel que não acompanham o OS X.

Para solucionar problemas específicos do kernel_task fora de controle , aqui estão alguns comandos úteis:

• Perfile o sistema inteiro, concentrando-se no processo do kernel (PID: 0), execute:

  sudo spindump 0 -reveal
  

  Para processos específicos (como launchd), use sample, por exemplo, sudo sample launchdou por PID.

• Para reunir o consumo de memória por tarefa do kernel, use (classificado por sujo por padrão):

  sudo footprint 0
  

  ^{Nota: Use -apara direcionar todos os processos.}

• Para reunir informações de diagnóstico de todo o sistema a partir de vários utils, execute: sudo sysdiagnose.

  Isso também pode ser acionado pressionando Shift- Control- ⌥- ⌘-. (ponto final).

  Você deve ver a tela piscando quando iniciada e aguarde alguns minutos até que o arquivo seja revelado no Finder .

  ^{Consulte: Como você obtém arquivos de diagnóstico do sistema no OS X?}

  Em seguida, descompactar e verificar os arquivos, como footprint*.txt, spindump.txt, taskinfo.txt, bc_stats.txte outros.

• Verifique vm.swapusagenos estados do kernel, por exemplo sysctl -a | grep ^vm.swapusage.

  Basicamente, quanto mais swap você usar (verifique os arquivos de troca nos /private/var/vmquais são gerenciados dynamic_pager, consulte :)man dynamic_pager , mais kernel terá problemas com o desempenho devido às operações de Swapins / Swapouts (consulte man vm_state man fs_usage). Para testar, execute:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Nota: Pressione Control- Cpara parar.}

Para mim, eu tive um processo (o Netbeans, neste caso, que estava lendo um arquivo como 20 GB) e usaria 80% da CPU para o NetBeans, 20% da CPU para o kernel_task (muito suspeito). Isso fez com que todo o meu sistema funcionasse como alcatrão.

Também suspeito é que "menumeters" reportariam muito tempo "sys", por CPU. Você também pode ver isso no comando "top", comoCPU usage: 21.40% user, 23.74% sys

Mais tarde, pode haver netbeans 120% da CPU, kernel_task 65%, mas de qualquer maneira ambos eram "alta CPU ao mesmo tempo"

sudo fs_usage mostrou muito disso:

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

Minha teoria é que o netbeans estava "lendo tanto" que estava causando falhas de página para executar seu próprio programa (ou seja, enviando para trocar seu próprio programa), obtendo uma fila atrás do sistema de falha de página. E provavelmente trocando "outros programas" para trocar também, fazendo com que todo o sistema fique lento.

Usando top, a coluna FAULT também estava aumentando em 70K / s.

Meu macbook Pro ficou quase inutilizável por causa da CPU alta do kernel_task por semanas. Ao mesmo tempo em que a bateria é inflada, finalmente decidi entrar no Apple Center em Roma para substituí-lo ... mesmo se fora da garantia, a Apple substituiu minha bateria (e teclado) por 0 € de custo. Ainda melhor ... problema kernel_task desaparece de repente !!! então eu tenho certeza que foi por causa da bateria, direta ou indiretamente