Perché la memoria trapelata appare malloced in kernel_task, e perché OS X non può quindi raccoglierlo

11

In precedenza mi è stato detto che un segno che alcune applicazioni hanno una perdita di memoria è che kernel_task ha un ingombro di memoria di grandi dimensioni, comunemente dell'ordine dei gigabyte. Se una percentuale errata di% co_de causava questo utilizzo della memoria, ci aspettiamo di vedere una discrepanza tra la memoria allocata e quelle che ci si aspetta che vengano allocate, ovvero

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

restituirebbe qualcosa di diverso dalle parole "Wired" e "Name".

Durante la stesura della mia tesi, ho notato che la modifica di un pdf mentre è aperta in Anteprima spesso causa brutte cose: occasionalmente, l'utilizzo della memoria di kext può aumentare fino a circa otto gigabyte o più. Se uccido l'anteprima, torna alla normalità, immediatamente . Quindi, ovviamente qualcosa non va - e Anteprima sta perdendo memoria in queste condizioni.

Quindi la mia domanda è questa: se I sa che un processo ha fatto trapelare ram attraverso un improvviso e inaspettato aumento dell'impronta di kernel_task , perché non può OS X sappi che qualcosa è andato storto. Se l'eliminazione dell'anteprima ripristina la memoria mancante di kernel_task d, perché non Darwin fa automaticamente la garbage collection per me?

Ho un malinteso fondamentale su come funziona la gestione della memoria?

EDIT: (15/9/15)

Ecco una dimostrazione di ciò di cui sto parlando. Prima di tutto, noto un utilizzo di memoria elevato di malloc() (nota Anteprima è aperta, appena visibile nella parte inferiore di Activity Monitor, utilizzando 333 MiB di ram):

SeguendoleutiliosservazionidiAshleydiseguito,scopriamoquantoognikextstausando:

$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
$

Quindi, non una quantità enorme. La mia macchina ha GPU discrete e integrate; i loro driver utilizzano solo pochi MiB di ram cablati. Sulla mia intuizione, uccidiamo Anteprima e guardiamo cosa succede all'impronta di memoria di kernel_task :

L'anteprima è sparita e l'ingombro della memoria del kernel è diminuito drasticamente. Non ci sono ancora prove di un cambiamento nell'uso di kext: l'output del comando precedente è invariato.

Modifica : errore segnalato come n. 22701036. Sto ancora aspettando una risposta da parte di Apple. Non c'è niente di particolarmente interessante se si ispeziona il processo in ActivityMonitor, ma forse mi manca qualcosa.

    
posta Landak 12.09.2015 - 11:11
fonte

2 risposte

6

Il nucleo di OS X non è un sistema di raccolta dei dati inutili; IOKit libkern C ++ Runtime richiede agli sviluppatori di gestire la propria memoria.

Gestione memoria Mac

Da Come funziona la gestione della memoria in Mac OS X?

Apple documents the lowest levels of the Mach Kernel and the virtual memory subsystem fairly well on the web as part of it's developer documentation.

Since that kernel was developed by Carnegie Mellon University, you can find dozens of papers describing it quite easily.

Altre fonti

Raccolta dati obsoleti

La raccolta dei dati inutili esiste a livello di utente o applicazione. Anche a questo livello, la garbage collection aiuta solo se l'applicazione ha rilasciato tutte le attestazioni alla memoria. Una dipendenza circolare può sconfiggere la raccolta dei rifiuti. La stessa Garbage Collection è un'area di ricerca in evoluzione e difficile da ottenere .

Segnala bug e perdite di memoria

Gli errori di OS X causeranno perdite di memoria. Data la dimensione del codice di base, questo è quasi certo.

Si prega di segnalare bug riproducibili direttamente ad Apple . Ogni segnalazione di bug aiuta e forse il tuo esempio sarà quello che aiuta gli ingegneri Apple a individuare la causa.

    
risposta data 15.09.2015 - 14:44
fonte
4

Ecco la mia ipotesi, supponendo che il tuo Mac abbia una GPU integrata (ad esempio Intel Iris Graphics).

Quando la tua tesi è aperta in anteprima, la memoria della scheda grafica viene utilizzata per contenere l'immagine ("texture") della finestra di anteprima e forse anche alcune pagine non schermate ma decodificate della tesi.

Con una scheda grafica integrata, la memoria video è in realtà (parzialmente?) situata nella RAM di sistema, che è condivisa tra CPU e GPU. Su alcune schede grafiche integrate, la quantità di RAM di sistema utilizzata viene allocata dinamicamente (vedi Apple HT204349 ).

Immagino che stai vedendo in modo intermittente un bug nel driver della scheda grafica e / o in Anteprima, che non sta rilasciando correttamente la memoria del sistema quando Anteprima ricarica il tuo PDF di tesi. (Tuttavia questo bug è mitigato da OS X / il driver rilascia la memoria correttamente quando Preview termina.)

Potresti provare a guardare l'output di kextstat e vedere se i numeri nella colonna Size aumentano quando si verifica il problema. La mia teoria è che l'aumento di 8 GB che menzioni sarà dovuto al driver della scheda grafica.

Il seguente comando (da un commento su questa risposta correlata e interessante ) ordina l'output di kextstat per renderlo più semplice per vedere quale kext usa la maggior parte della memoria (anche se nota questo ordinamento dalla colonna Wired ... c'è un incantesimo simile, più semplice in questa risposta con una spiegazione se desideri modificare questo aspetto.

kextstat | awk 'NR==1{ printf "%10s %s\n", $5, $6; } NR!=1{ printf "%10d %s\n", $5, $6; }' | sort -n
    
risposta data 15.09.2015 - 11:50
fonte

Leggi altre domande sui tag