Почему пропущенная память отображается в файле kernel_task, и почему OS X не может ее удалить?

Мне ранее говорили, что знак того, что какое-то приложение имеет утечку памяти, состоит в том, что kernel_task имеет большой объем памяти, обычно на порядка гигабайт. Если для этого использования памяти использовался awry kext, мы ожидаем увидеть несоответствие между выделенной памятью и ожидаемыми выделениями, то есть

diff <(kextstat|tr -s ' ' | cut -d ' ' -f 5) <(kextstat| tr -s ' ' | cut -d ' ' -f 6) 

будет возвращать нечто иное, чем слова «Wired» и «Name».

Во время написания моей диссертации я заметил, что изменение pdf-файла, пока оно открыто в Preview, часто приводит к возникновению плохих вещей: иногда использование памяти kernel_task может вырасти примерно до восьми гигабайт или более. Если я убью предварительный просмотр, он возвращается в нормальное состояние, мгновенно . Итак, очевидно, что-то не так - и Предварительный просмотр утечки памяти в этих условиях.

Итак, мой вопрос таков: если I знает, что процесс просочился из-за внезапного и неожиданного увеличения отпечатка kernel_task, почему не может OS X знать, что что-то пошло не так. Если убийство Preview восстанавливает мою недостающую malloc() 'd память, почему не Дарвин делает сборку мусора автоматически для меня ?

Есть ли у меня фундаментальное непонимание того, как работает управление памятью?

РЕДАКТИРОВАТЬ: (15/9/15)

Вот демонстрация того, о чем я говорю. Прежде всего, я замечаю, что использование большой памяти с помощью kernel_task (примечание Предварительный просмотр открыт, только что видимый внизу Монитора активности, используя 333 MiB ):

 Использование памяти с высоким ядром

Следуя полезным замечаниям Эшли ниже, давайте выясним, сколько использует каждый kext:

$ kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n

...
...
...
   1249280 com.apple.driver.DspFuncLib
   1769472 com.apple.nvidia.driver.NVDAGK100Hal
   2629632 com.apple.nvidia.driver.NVDAResman
   6184960 com.apple.driver.AirPort.Brcm4360
$

Так что, не огромная сумма. Моя машина имеет как дискретные, так и встроенные графические процессоры; их водители используют только несколько MiB проводного барана. На мой взгляд, давайте убьем Preview и посмотрим, что происходит с размером памяти kernel_task:

 Предварительный просмотр убийства помогает

Предварительный просмотр пропал, а объем памяти ядра значительно снизился. До сих пор нет доказательств изменения использования kext: вывод вышеуказанной команды не изменился.

Изменить : ошибка, указанная как № 22701036. Я все еще жду ответа от яблока. Нет ничего особенно интересного, если вы проверите процесс в ActivityMonitor, но, возможно, мне что-то не хватает.

11 голосов | спросил Landak 12 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowSat, 12 Sep 2015 12:11:10 +0300 2015, 12:11:10

2 ответа


6

ядро ​​OS X не собирает мусор ; IOKit libkern C ++ Runtime требует от разработчиков управления собственной памятью.

Управление памятью Mac

Из Как работает управление памятью в Mac OS X?

  

Apple документирует самые низкие уровни Мах-ядро и виртуальную память подсистемы достаточно хорошо в Интернете как часть документации разработчика.

     

Поскольку это ядро ​​было разработано Карнеги Mellon University , вы можете найти десятки документы описывая это довольно легко.

Другие источники

Сбор мусора

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

Сообщить об ошибках и утечках памяти

Ошибки в OS X будут утечки памяти. Учитывая размер базы кода, это почти наверняка.

Пожалуйста, сообщите воспроизводимые ошибки прямо в Apple . Каждый отчет об ошибках помогает, и, может быть, ваш пример будет тем, который помогает инженерам Apple вывести причину.

ответил Graham Miln 15 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 15 Sep 2015 15:44:55 +0300 2015, 15:44:55
4

Вот моя догадка, предполагая, что ваш Mac имеет интегрированный графический процессор (например, графику Intel Iris).

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

Со встроенной графической картой видеопамять фактически (частично?) находится в системной памяти, которая распределяется между ЦП и ГПУ. На некоторых интегрированных графических картах количество используемой оперативной памяти динамически распределено (см. Apple HT204349 ).

Я бы предположил, что вы периодически наблюдаете ошибку в драйвере графической карты и /или Preview, которая не освобождает системную память правильно, когда Preview перезагружает ваш PDF-файл. (Однако эта ошибка смягчается OS X /драйвер, правильно освобождающий память, когда Query Preview завершает работу.)

Вы можете попробовать посмотреть результат kextstat и посмотреть, будут ли номера в Size при возникновении проблемы. Моя теория состоит в том, что увеличение 8 ГБ, о котором вы упоминаете, будет связано с драйвером видеокарты.

Следующая команда (из комментария этого связанного и интересного ответа ) сортирует вывод kextstat, чтобы было легче увидеть, какой kext использует большую часть памяти (хотя обратите внимание на этот вид Wired ... есть аналогичное, более простое заклинание в этом ответе с объяснением, если вы хотели бы настроить это).

kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n
ответил Ashley 15 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 15 Sep 2015 12:50:14 +0300 2015, 12:50:14

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132