Récemment, j’ai remarqué que ma durée de vie de la batterie avait fortement chuté et que le processus "kernel_task" utilisait pas mal de ressources processeur (une constante de 1 à 6% sur mon processeur dual-core i7 de 2010, MBP de 2,8 GHz). Évidemment, je pense que l'utilisation du processeur par kernel_task contribue à la perte de batterie et je dois trouver pourquoi.
Kernel_task est la version OS X du "svchost.exe" de Windows - le processus notoire do-everything que vous ne pouvez jamais vraiment déboguer, vous devez simplement basculer manuellement les commutateurs jusqu'à ce que l'un d'eux fonctionne.
Y a-t-il un moyen que je puisse plus facilement aller au fond de l'activité kernel_task hors de contrôle? Je n'ai pas essayé de redémarrer, car si cela le "résout", cela ne résout pas vraiment le problème sous-jacent.
Moniteur d'activité indique l'utilisation du processeur. Lorsque j'appuie sur Inspect, il affiche 77 threads, 2 ports, des heures et des heures de temps processeur, les commutateurs de contexte augmentent d'environ 400 par seconde et les messages Mach In et Out augmentent tous les deux à environ 6 000 par seconde.
Comment puis-je en quelque sorte inspecter ou surveiller ce kernel_task
processus et déterminer ce qui utilise réellement tout ce pouvoir?
(Remarque: mes suspects actuels sont la récente mise à jour 10.6.7, la mise à jour de Firefox de la 4 beta 10 à la RC, ou ScreenResX - ce sont toutes les choses que j'ai faites récemment et auxquelles je peux penser.)
la source
kernel_task
comme hors de contrôle. Le Moniteur d'activité n'est peut-être pas le meilleur utilitaire pour les diagnostics dans ce domaine. Dans la console, ajoutez des requêtes de journal système pour vous aider à identifier les différentes manières dont les tâches du noyau sont utilisées. puis affinez la question d’ouverture en une question à laquelle il sera plus facile de répondre.Réponses:
J'avais une question similaire sur la façon d'identifier les fichiers et les programmes connectés à kernal_task à l'aide de la commande de terminal suivante:
Cela affichera divers kexts et la mémoire qui leur est associée. Par exemple,
6184960 com.apple.driver.AirPort.Brcm4360
c'est un gros porc pour moi, mais je ne peux rien y faire si je veux utiliser le wifi.Une des suggestions que j'ai reçues était de rechercher tous les kexts non-Apple utilisant de la mémoire en lançant la procédure ci-dessus
grep -v com.apple
. Il est possible que certains programmes non-Apple utilisent vos ressources. Vous devriez pouvoir les enlever sans rien casser.La solution ancienne est bien sûr de redémarrer votre ordinateur. Parfois, il suffit de ramener les processus à leur niveau normal d’utilisation du processeur.
la source
man kextstat
, en regardant cela et laawk
saisie de commande$4
, cela ressemble à la taille de l'utilisation de la mémoire kext. Cela a du sens compte tenu de la question.Voici une excellente explication de ce qu’est une tâche de noyau. Il peut s'agir de pilotes (kexts), d'activités réseau ou de disques. Vous ne pouvez pas simplement utiliser des instruments pour vous connecter au
kernel_task
processus.Recherchez d’autres signes, tels que les journaux (Console.app), l’activité du disque (par exemple:), l’activité du
iotop
fs_usage
réseau (essayez de vous déconnecter du réseau local, désactivez les périphériques dans les préférences réseau), essayez de désinstaller / de supprimer leskextunload
pilotes de la mémoire ( ), qui proviennent de tiers - tablettes, modems usb 3g, etc. Vérifiez les applications qui installent des kextsAssurez-vous également que votre système de fichiers n'est pas corrompu. Si vous avez eu un crash récemment, effectuez une vérification.
la source
kernel_task
était de retour à des niveaux sains d'activité.Comme mentionné par @Christopher, la chaleur peut provoquer un pic du processeur kernel_task. La raison en est citée dans cet article «Correction» des problèmes de processeur kernel_task sous MacOS Lion 10.7 . Apparemment, lorsque le processeur chauffe, ACPI_SMC_PlatformPlugin.kext prendra des cycles de processeur pour tenter de réduire la charge réelle du processeur.
Une solution consiste donc à refroidir votre Mac (par exemple, un ventilateur) via un ventilateur externe ou quelque chose comme SMCFanControl .
L'article donne une autre solution qui consiste à supprimer le sous-kext qui déclenche ce comportement. Bien que je dois avouer que je ne suis personnellement pas sûr de la sécurité à laquelle on peut mettre un tel comportement.
la source
Il
kernel_task
est généralement hors de contrôle lorsque d'autres processus utilisent trop d'appels système ou de ressources (événements de mémoire ou d'E / S de disque).Lorsque cela se produit, vous pouvez utiliser l'
fs_usage
utilitaire de génération de rapports qui affiche en temps réel les appels système et les erreurs de page liées à l'activité du système de fichiers.Alors exécutez cette commande dans Terminal:
Ensuite, observez quels processus effectuent fréquemment des appels système et si vous ne les utilisez pas, envisagez de les fermer / de les supprimer.
Pour plus de précision, consultez la colonne TIME INTERVAL qui indique le temps écoulé dans l'appel système. Une
W
apparition après le temps écoulé indique que le processus était une activité planifiée (dans ce cas, le temps écoulé comprend le temps d'attente).Donc, afin de filtrer les processus qui utilisent le plus grand intervalle de temps dans les appels système, exécutez:
qui vous montrera dans la dernière colonne les processus les plus gourmands (en terme de temps noyau). Vous pouvez ajuster le nombre de zéros pour plus de précision (moins de zéros affichés, plus de temps passé).
Pour plus d’idées, consultez également: Comment étudier l’utilisation élevée de la mémoire des tâches du noyau?
Voici les problèmes les plus courants:
VBoxHeadless
: si vous utilisez des machines virtuelles (via vagabond), envisagez de les suspendre lorsqu'elles ne sont pas utilisées;mtmd
: il semble que Time Machine sauvegarde vos données toutes les heures même lorsque votre lecteur de sauvegarde n'est pas connecté ( instantanés locaux ), essayez donc de le désactiver (sudo tmutil disablelocal
);wine
: si vous utilisez des applications Windows, envisagez de les fermer lorsque vous ne les utilisez pas;Chrome
: limite le nombre d'onglets ouverts simultanément (essayez OneTab et / ou TGS ) ou supprimez certains processus d'extension ( JavaScript ) via le Gestionnaire de tâches , car chaque onglet pourrait générer un processus distinct.Vérifiez: Chrome addon pour arrêter le message "Page (s) Unresponsive" .
la source
grep
lui - même:sudo fs_usage | grep -v -e '0.0000' -e 'iTerm2' -e 'grep'
L’utilisation du processeur dans kernel_task a fortement augmenté, et il est apparu que mon ventilateur du processeur était partiellement débranché. kernel_task a quelque chose à voir avec la limitation du CPU quand il fait trop chaud. Dans votre cas, peut-être votre ventilateur est-il juste recouvert de poussière et d’ordures, et doit être nettoyé.
la source
J'ai eu le même problème à Yosemite mais grâce à cette bonne âme basée sur celle-ci, un autre bon camarade, j'ai pu le résoudre. Je n'arrive toujours pas à comprendre ce qui s'est passé, mais après avoir perdu tout un week-end à essayer de régler le problème, j'ai tout simplement abandonné et suivi aveuglément ses instructions. Regardez mon désespoir dans le moniteur d'activité:
Soyez prudent, faites toujours d'abord une sauvegarde et lisez les liens fournis pour des explications. Je n'assume aucune responsabilité pour les dommages causés. Tu as été prévenu.
la source
Je suis sur OSX Lion avec un nouveau macbook pro 2011 et j’ai récemment eu kernel_task exécutant environ 25-30% du processeur et mon ventilateur tournait à plein régime pendant des heures et des heures. J'ai essayé une chose à la fois et ce qui a été résolu ... la fermeture de 5 ou 6 fenêtres dans l'application Finder. Je ne peux pas dire que je comprends pourquoi, mais c'était clairement cela.
la source
Sur mon Mac, l'utilisation de kernel_task par le processeur est proportionnelle à la bande passante Internet que j'utilise, allant d'environ 0% à 50%. Cela est probablement dû aux pilotes de mon modem Huawei 3G (HuaweiDataCardDriver.kext).
Vous pouvez essayer de désactiver les extensions de noyau. Il n'est pas nécessaire d'utiliser kextunload: vous pouvez simplement déplacer les ensembles de kext de / System / Library / Extensions / vers un autre dossier, puis redémarrer. Vous pouvez utiliser Consultant Canary ou
kextstat | grep -v com.apple
répertorier les extensions de noyau qui ne sont pas fournies avec OS X.la source
Pour résoudre spécifiquement le problème de kernel_task hors de contrôle , voici quelques commandes utiles:
Définissez le système entier en vous concentrant sur le processus du noyau (PID: 0), exécutez:
Pour un processus spécifique (comme
launchd
), utilisezsample
, par exemple,sudo sample launchd
ou par PID.Pour collecter la consommation de mémoire par tâche du noyau, utilisez (trié par dirty):
Remarque: Utilisez
-a
pour cibler tous les processus.Pour recueillir des informations de diagnostic système à l' échelle de plusieurs utils, exécutez:
sudo sysdiagnose
.Cela peut également être déclenché en appuyant sur Shift- Control- ⌥- ⌘-. (point).
L'écran devrait clignoter au démarrage, puis attendez quelques minutes jusqu'à ce que le fichier soit révélé dans le Finder .
Voir: Comment obtenir des fichiers de diagnostic système sous OS X?
Ensuite , décompressez et vérifier les fichiers tels que
footprint*.txt
,spindump.txt
,taskinfo.txt
,bc_stats.txt
et d' autres.Vérifier
vm.swapusage
les états du noyau, par exemplesysctl -a | grep ^vm.swapusage
.En gros, plus vous utilisez d’ échanges (vérifiez les fichiers d’échange dans
/private/var/vm
lesquels sont gérésdynamic_pager
, voir :)man dynamic_pager
, plus le noyau a de la difficulté à obtenir des performances en raison des opérations Swapins / Swapouts (voirman vm_stat
etman fs_usage
). Pour tester, lancez:Note: Hit Control- Cpour arrêter.
la source
Pour moi, j'avais un processus (Netbeans dans ce cas, qui lisait un fichier comme 20 Go) et il utilisait comme 80% de CPU pour les netbeans, 20% de CPU pour kernel_task (très suspect). Cela a fait fonctionner tout mon système comme du goudron.
Aussi suspect est que "menumeters" rapporterait beaucoup de "sys" temps, par cpu. Vous pouvez aussi voir cela dans la commande "top", comme
CPU usage: 21.40% user, 23.74% sys
Plus tard, il pourrait s’agir de 120% de processeurs netbeans, 65% de kernel_task, mais quoi qu’il en soit, ils étaient tous les deux "élevés en même temps"
sudo fs_usage
a montré beaucoup de cela:Ma théorie est que netbeans "lisait tellement" qu'il causait même les erreurs de page à exécuter son propre programme (c'est-à-dire l'envoi pour échanger son propre programme), créant ainsi une file d'attente derrière le système d'erreur de page. Et probablement en échangeant "d'autres programmes", ce qui a pour effet de rendre le système tout à fait fou.
En utilisant
top
, la colonne FAULT augmentait également de 70K / sec.la source
Mon Macbook Pro était presque inutilisable pendant plusieurs semaines à cause du taux de CPU élevé de kernel_task. Au même moment, la batterie se gonflait. J'ai donc finalement décidé de me rendre sur Apple Center à Rome pour le remplacer. clavier aussi) pour 0 € coût. Encore mieux ... le problème de kernel_task disparaît soudainement !!! donc je suis à peu près sûr que c'était à cause de la batterie, directement ou indirectement
la source