Как диагностировать раздувание OS X kernel_task и использование проводной памяти?


18

У меня очень странная проблема, с которой мне сложно определить причину.

У меня есть Mac Pro (2008, 8-ядерный 2,8 ГГц, 8800GT) с 14 ГБ ОЗУ (недавно обновленный из-за этой проблемы!).

Когда я загружаю свою систему и захожу в систему, vm_stat / top / Activity Monitor покажет, что в kernel_task выделено около 150 МБ, а на машине выделено около 800 МБ выделенной проводной памяти.

Даже на начальном этапе 800 МБ кажутся огромным количеством проводной памяти, которая должна быть выделена без запуска приложений, но становится еще хуже. (Примечание: проводная связь заблокирована, память не удаляется )

Через очень короткое время, иногда вызываемое чем-то простым, например, запуском терминала, kernel_task увеличится до 8-900 МБ Real Mem (RSIZE), а проводная память ускорится до 1,6 ГБ (подразумевая, что все дополнительные запросы памяти предназначены для проводная оперативная память в ядре).

Если я закрою все (IE: нет запущенных приложений, заблокирую монитор активности или терминал для просмотра сверху), то не произойдет заметного сокращения ни kernel_task RSIZE, ни использования проводной памяти. Если пойти в обратном направлении и загрузить систему задачами, это также показывает, что проводная память не уменьшается, и, что важно, она не уменьшается в зависимости от интенсивной замены.

Если я выйду из системы и снова войду в нее, это немного уменьшится (450 МБ kernel_task, 1,28 ГБ Wired), но не обратно.

Я не запускаю никаких дурацких kext s - и, кроме того, kextstat не показывает там огромного распределения памяти; самое большое из них - com.apple.nvidia.nv50hal с объемом памяти около 4 МБ.

Машина чувствует себя в целом более вялой, когда это произошло, что неудивительно, потому что такой огромный объем оперативной памяти был помечен как нестраничный.

Итак, у меня есть несколько вопросов:

1) Есть ли хороший способ диагностировать, что выделило всю эту проводную память? Это часто более чем в 2 раза превышает размер kernel_task, без запуска приложений. Реальное общее количество памяти, кажется, не складывается - кажется, что есть куча оперативной памяти, которая нигде не учитывается.

2) Что происходит, чтобы заставить ядро ​​внезапно потребовать в 6 раз больше памяти?


1
Вероятно, связано с этим code.google.com/p/chromium/issues/detail?id=345664
jackkav

Ответы:


5

Чтобы выяснить, почему ядро ​​использует больше памяти, чем обычно, вы можете использовать различные инструменты.

  1. Запустите Activity Monitor, чтобы проверить, какие процессы используют больше памяти, так что это либо kernel_taskлюбая другая задача, использующая больше памяти, чем обычно (затем подумайте об ее уничтожении).
  2. Запустите в Терминале, vm_stat 1чтобы увидеть статистику памяти в реальном времени и, если ваша память действительно увеличивается каждую секунду.
  3. Запустите fs_usage(как root) инструмент для мониторинга системных вызовов и ошибок страниц в режиме реального времени.
  4. Чтобы проверить сумму грязных / анонимных распределений нескольких процессов, запущенных в Терминале:

    sudo footprint -all -categories -swapped -collapseSharing
    

    Он собирает информацию о памяти, такую ​​как объем обмена (на пользователя или память ядра).

  5. Более того, если вы думаете, что ядро ​​использует большую часть памяти, попробуйте zprintинструмент:

    sudo zprint -t -s | head -n20
    

    Он покажет информацию о зонах ядра

Если вы хотите принудительно очистить кэш диска (чтобы освободить часть памяти), вы можете попробовать:

sync && sudo purge

См. Также: Как исследовать интенсивное использование памяти задач ядра? в AD SE


3

Расширения ядра - это лишь один из множества фрагментов кода, которые могут выполняться операционной системой без вашего ведома. У меня есть небольшая утилита на основе Python под названием «Консультант Канарский», которая поможет вам найти довольно много из них:

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.