Совсем недавно я заметил, что время работы от батареи довольно сильно сократилось, и процесс «kernel_task» использует довольно много ресурсов процессора (постоянная 1-6% на моем 2,8 ГГц двухъядерном i7, 2010 MBP). Очевидно, я думаю, что использование процессора kernel_task способствует снижению заряда батареи, и мне нужно выяснить, почему.

Поиском в Google кажется, что kernel_task является версией OS X для Windows "svchost.exe" - пресловутого процесса все, что вы не можете отладить по-настоящему, вам просто нужно вручную переключать переключатели, пока один из них не заработает.

Есть ли способ, которым я могу более легко добраться до сути неконтролируемой активности kernel_task? Я не пробовал перезагрузку, потому что, если это «исправляет» это, это не решает основную проблему.

Монитор активности показывает использование процессора. Когда я нажимаю Inspect, он показывает 77 потоков, 2 порта, часы и часы процессорного времени, переключатели контекста повышаются примерно до 400 в секунду, а входы и выходы сообщений Mach - около 6000 в секунду.

Как я могу как-то проверить или контролировать этот kernel_taskпроцесс и выяснить, что на самом деле использует всю эту мощь?

_{(примечание: мои нынешние подозреваемые - это недавнее обновление 10.6.7, обновление Firefox с 4 beta 10 до RC или ScreenResX - это все, что я недавно сделал, о котором я могу думать)}

У меня был похожий вопрос о том, как определить файлы и программы, связанные с kernal_task, используя следующую терминальную команду:

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

Это покажет различные кексы и память, связанную с ними. Например, 6184960 com.apple.driver.AirPort.Brcm4360это большая свинья для меня, но я не могу ничего с этим поделать, если я хочу использовать Wi-Fi.

Одно из предложений, которое я получил, было посмотреть, что все не-Apple kexts занимают память, передавая вышеизложенное grep -v com.apple. Вполне возможно, что некоторые не-Apple программы используют ваши ресурсы. Вы должны быть в состоянии удалить их, ничего не нарушая.

Конечно, старое решение - перезагрузить компьютер. Иногда это все, что нужно, чтобы вернуть процессам их нормальный уровень использования процессора.

Вот отличное объяснение, что такое kernel_task. Это могут быть драйверы (kexts), сетевая или дисковая активность. Вы не можете просто использовать инструменты, чтобы присоединиться к kernel_taskпроцессу.

Найдите другие признаки, такие как журналы (Console.app), активность диска (например:) iotop fs_usage, сетевую активность (попробуйте отключиться от локальной сети, отключить устройства в настройках сети), попытаться удалить / удалить из памяти ( kextunload) драйверы, которые от сторонних производителей - планшеты, USB 3G модемы и т. д. Проверьте приложения, которые устанавливают kexts.

Также убедитесь, что ваша файловая система не повреждена, если у вас были какие-либо сбои в последнее время - проверьте.

Как упомянул @Christopher, высокая температура может вызвать скачок в процессоре kernel_task. Причина перечислена в этом посте «Исправление» kernel_task Проблемы с процессором в MacOS Lion 10.7 . Очевидно, когда ЦП нагревается, ACPI_SMC_PlatformPlugin.kext будет загружать циклы ЦП в попытке уменьшить фактическую загрузку ЦП.

Поэтому одним из решений является охлаждение вашего Mac (например, вентилятора) через внешний вентилятор или что-то вроде SMCFanControl .

В статье дано другое решение, которое заключается в удалении подтекста, который запускает такое поведение. Хотя я должен признать, что лично я не уверен, насколько безопасно отключать такое поведение.

Обычно kernel_taskвыходит из-под контроля, когда некоторые другие процессы используют системные вызовы или ресурсы (события ввода-вывода памяти или диска).

Когда это происходит, вы можете использовать fs_usageутилиту отчетности, которая в режиме реального времени покажет вам системные вызовы и сбои страниц, связанные с деятельностью файловой системы.

Запустите эту команду в Терминале:

sudo fs_usage

затем проследите, какие процессы часто выполняют некоторые системные вызовы, и, если вы их не используете, подумайте о том, чтобы закрыть / убить их.

Чтобы быть более конкретным, пожалуйста, проверьте столбец ИНТЕРВАЛ ВРЕМЕНИ, в котором указано время, проведенное в системном вызове. WПоявляться после того, как истекшее время показывает процесс был запланирован выходом активности (в этом случае истекшее время включает в себя время ожидания).

Таким образом, чтобы отфильтровать процессы, которые используют наибольший интервал времени в системных вызовах, выполните:

sudo fs_usage | grep -v 0.0000

который покажет вам в последнем столбце самые голодные процессы (с точки зрения времени ядра). Вы можете отрегулировать количество нулей для точности (меньше отображаемых нулей, больше времени).

Для большего количества идей также проверьте: Как исследовать интенсивное использование памяти задач ядра?

Вот наиболее распространенные проблемы:

• VBoxHeadless: если вы используете виртуальные машины (через vagrant), рассмотрите возможность их приостановки, когда они не используются;
• mtmd: кажется, что Time Machine выполняет резервное копирование ваших данных каждый час, даже если ваш резервный диск не подключен (так называемые локальные снимки ), поэтому попробуйте отключить его ( sudo tmutil disablelocal);
• wine: если вы работаете с приложениями Windows, подумайте о том, чтобы закрыть их, когда они не используются;

• Chrome: ограничить количество одновременно открытых вкладок (попробуйте OneTab и / или TGS ) или убить некоторые процессы расширения ( JavaScript ) с помощью диспетчера задач , поскольку каждая вкладка может генерировать отдельный процесс.

  ^{Проверьте: добавление Chrome для остановки сообщения «Страница не отвечает» .}

У меня был резкий скачок загрузки процессора kernel_task, и оказалось, что мой вентилятор процессора был частично отключен. kernel_task как-то связан с регулированием процессора, когда он становится слишком горячим. В вашем случае, возможно, ваш вентилятор просто забит мусором и пылью, и его нужно почистить.

У меня была такая же проблема в Йосемити, но благодаря этой хорошей душе, основанной на этом другом, я смог ее решить. Я до сих пор не могу понять, что произошло, но, потеряв целые выходные, пытаясь разобраться, я просто сдался и слепо следовал его инструкциям. Посмотрите на мое отчаяние в мониторе активности:

Будьте осторожны, всегда делайте резервную копию сначала и прочитайте предоставленные ссылки для объяснения. Я не несу никакой ответственности за любой причиненный ущерб. Вы были предупреждены.

Найти модель

$ system_profiler -detailLevel mini | grep "Идентификатор модели:"

Идентификатор модели: MacBookPro8,2

Переместить и сделать резервную копию файла

$ mkdir -p ~ / backup

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

$ sudo mv MacBookPro8_2.plist ~ / backup /

Я работаю на OSX Lion с новым MacBook Pro 2011 года, и у меня недавно был kernel_task, работающий на 25-30% процессорного времени, и мой вентилятор вращался с максимальной скоростью в течение нескольких часов. Я пытался по одной вещи за раз, и что решило это было закрытие 5 или 6 окон в приложении Finder. Не могу сказать, что понимаю почему, но это было ясно.

На моем Mac использование CPU kernel_task пропорционально используемой мной пропускной способности интернета, в диапазоне от 0% до 50%. Вероятно, это связано с драйверами для моего 3G-модема Huawei (HuaweiDataCardDriver.kext).

Вы можете попробовать отключить расширения ядра. Нет необходимости использовать kextunload: безопасно просто переместить пакеты kext из / System / Library / Extensions / в другую папку и перезапустить. Вы можете использовать Canary консультанта или kextstat | grep -v com.appleперечислить расширения ядра, которые не поставлялись с OS X.

Для устранения проблем из-под контроля kernel_task, в частности, вот несколько полезных команд:

• Профилируйте всю систему, ориентируясь на процесс ядра (PID: 0), запустите:

  sudo spindump 0 -reveal
  

  Для конкретного процесса (например launchd), используйте sample, например, sudo sample launchdили с помощью PID.

• Чтобы собрать потребление памяти для задачи ядра, используйте (по умолчанию отсортировано по грязному):

  sudo footprint 0
  

  ^{Примечание. Используйте -aдля настройки всех процессов.}

• Для того, чтобы собрать общесистемную диагностическую информацию из нескольких утилитов, запустите: sudo sysdiagnose.

  Это также может быть вызвано нажатием Shift- Control- ⌥- ⌘-. (точка).

  При запуске вы должны увидеть мигающий экран, затем подождите несколько минут, пока файл не будет найден в Finder .

  ^{Смотрите: Как вы получаете системные диагностические файлы от OS X?}

  Затем распаковывать и проверять файлы , такие как footprint*.txt, spindump.txt, taskinfo.txt, bc_stats.txtи другие.

• Проверьте vm.swapusageв состояниях ядра, например sysctl -a | grep ^vm.swapusage.

  В основном, чем больше вы используете своп (проверьте файлы подкачки, в /private/var/vmкоторых они управляются dynamic_pager, см . :)man dynamic_pager , тем больше у ядра проблемы с производительностью из-за операций Swapins / Swapouts (см. man vm_statИ man fs_usage). Чтобы проверить, запустите:

  vm_stat 1
  sudo fs_usage | grep -w kernel_task
  

  ^{Примечание: нажмите Control- Cчтобы остановить.}

Для меня у меня был один процесс (в данном случае Netbeans, который считывал файл размером около 20 ГБ), и он использовал бы 80% ЦП для сетевых компонентов, 20% ЦП для kernel_task (очень подозрительно). Это заставило мою систему работать как tar.

Также подозрительным является то, что «menumeters» сообщают о большом количестве «sys» времени на процессор. Вы также можете увидеть это в команде "top", напримерCPU usage: 21.40% user, 23.74% sys

Позже, это может быть netbeans 120% CPU, kernel_task 65%, но в любом случае они оба были «высокопроизводительными процессорами одновременно»

sudo fs_usage показал много этого:

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

Моя теория заключается в том, что netbeans «так много читал», что он вызывал сбои страниц даже при запуске собственной программы (то есть при отправке для замены своей собственной программы), так что получалась очередь за системой сбоев страниц. И, вероятно, также поменять местами «другие программы», что приведет к замедлению работы всей системы.

При topиспользовании столбец FAULT также увеличивался на 70K / сек.

Мой macbook Pro был почти непригоден из-за высокой загрузки CPU в течение нескольких недель. В то же время батарея раздувалась, поэтому я наконец решил пойти в Apple Center в Риме, чтобы заменить его ... даже если из-за гарантии Apple заменила мою батарею (и клавиатура) за 0 €. Еще лучше ... проблема kernel_task внезапно исчезает !!! так что я уверен, что это было из-за батареи, прямо или косвенно