Por que o launchd continua matando processos

Question

Eu notei que o meu system.log está sendo inundado com mensagens como esta:

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.]

Eu entendo que o launchd pode matar processos quando a RAM está cheia, mas eu acho que tenho muita RAM (32GB). Geralmente, tenho uma quantidade muito pequena de memória livre, mas sempre há mais de 15 GB de memória "inativa" quando verifico o Activity Monitor. Isso não está realmente causando nenhum problema, mas eu gostaria de organizar meu arquivo de log para que eu possa ver problemas reais com mais facilidade.

    

Answer 1

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

Isso é launchd relatando que um processo iniciado (número 8564, denominado "com.apple.audio.ComponentHelper") foi inesperado porque foi enviado sinal 9 (SIGKILL).

A causa é, na verdade, indicada pela linha subseqüente (em vez da anterior) no seu snippet de log.

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

(Parece que o syslog acabou de processar e / ou liberou as linhas fora de ordem.) O assassino é o próprio kernel. De acordo com este (veja o segundo parágrafo no cabeçalho "MemoryStatus and Jetsam"), no OS X, o thread memorystatus do kernel reage a memória livre abaixo de um certo limite, matando processos "marcados para saída inativa".

Então, o kernel estava matando processos em um último esforço para evitar ficar sem RAM livre. Eu também ficaria cético com muita RAM, mas é isso que essas entradas de log parecem indicar. Observe que a memória "inativa" não está livre ou "não é mais necessária". A memória inativa é simplesmente a menos acessada recentemente da memória atualmente alocada. Não está disponível para reutilização, a menos e até que seu conteúdo tenha sido trocado para o disco. (Eu encontrei esta explicação muito útil.) Seu arquivo de troca estava cheio? Alternativamente, gostaria de saber se isso poderia acontecer se o pager simplesmente não conseguisse gravar em disco com rapidez suficiente para acompanhar uma súbita explosão de alocação (e escrita real).