Почему launchd продолжает убивать процессы

Question

Я заметил, что мой system.log заполняется сообщениями вроде этого:

May  5 12:56:08 macpro com.apple.launchd[1] (com.apple.qtkittrustedmoviesservice[8568]): Exited: Killed: 9
May  5 12:56:08 macpro kernel[0]: memorystatus_thread: idle exiting pid 8568 [qtkittrustedmovi]
May  5 12:56:11 macpro com.apple.launchd[1] (com.apple.audio.ComponentHelper[8564]): Exited: Killed: 9
May  5 12:56:11 macpro kernel[0]: memorystatus_thread: idle exiting pid 8564 [com.apple.audio.]
May  5 12:56:12 macpro com.apple.launchd[1] (com.apple.sleepservicesd[8572]): Exited: Killed: 9
May  5 12:56:12 macpro kernel[0]: memorystatus_thread: idle exiting pid 8572 [SleepServicesD]
May  5 12:56:12 macpro com.apple.launchd[1] (com.apple.audio.SandboxHelper[8563]): Exited: Killed: 9
May  5 12:56:12 macpro kernel[0]: memorystatus_thread: idle exiting pid 8563 [com.apple.audio.]

Я понимаю, что launchd может убивать процессы при заполнении ОЗУ, но я думаю, что у меня достаточно ОЗУ (32 ГБ). Обычно у меня очень мало свободной памяти, но при проверке Activity Monitor всегда остается более 15 ГБ "неактивной" памяти. Это на самом деле не вызывает никаких проблем, но я хотел бы очистить мой лог-файл, чтобы мне было легче видеть реальные проблемы.

Answer 1

com.apple.launchd[1] (com.apple.audio.ComponentHelper[8564]): Exited: Killed: 9

Это launchd сообщение о том, что процесс, который он запустил (номер 8564, с именем "com.apple.audio.ComponentHelper ") неожиданно завершил работу, поскольку ему был отправлен сигнал 9 (SIGKILL).

Фактически причина указана в следующей (а не в предыдущей) строке в вашем фрагменте журнала.

kernel[0]: memorystatus_thread: idle exiting pid 8564 [com.apple.audio.]

(Кажется, системный журнал только что обработал и / или очистил строки.) Убийца - это само ядро. Согласно этому (см. Второй абзац под заголовком "MemoryStatus и Jetsam"), в OS X поток памяти ядра ядра реагирует на падение свободной памяти ниже определенного порога, убивая процессы, "помеченные для выхода из режима ожидания".

Таким образом, ядро убивало процессы, пытаясь избежать нехватки ОЗУ. Я бы тоже скептически отнесся к такому объему оперативной памяти, но, похоже, именно на это указывают записи в журнале. Обратите внимание, что "неактивная" память не свободна или "больше не нужна". Неактивная память - это просто наименее доступ к памяти, выделенной в данный момент. Он не доступен для повторного использования до тех пор, пока его содержимое не будет перенесено на диск. (Я нашел это объяснение очень полезным.) Ваш файл подкачки был заполнен? В качестве альтернативы, мне интересно, могло ли это произойти, если пейджер просто не мог записать на диск достаточно быстро, чтобы не отставать от внезапного всплеска выделения (и фактической записи).