Mi è stato precedentemente detto che un segno che alcune applicazioni hanno una perdita di memoria è che kernel_taskha un ingombro di memoria elevato, comunemente nell'ordine dei gigabyte. Se un uso errato della kextmemoria causasse questo utilizzo della memoria, ci aspetteremmo di vedere una discrepanza tra la memoria allocata e quelle che dovrebbero essere allocate, vale a dire
diff <(kextstat|tr -s ' ' | cut -d ' ' -f 5) <(kextstat| tr -s ' ' | cut -d ' ' -f 6)
restituirebbe qualcosa di diverso dalle parole "Wired" e "Name".
Mentre scrivo la mia tesi, ho notato che la modifica di un pdf mentre è aperto in Anteprima spesso causa cose brutte: occasionalmente, l'utilizzo della memoria kernel_taskpuò arrivare a circa otto gigabyte o più. Se uccido l'anteprima, ritorna alla normalità, all'istante . Quindi, ovviamente qualcosa non va - e in queste condizioni l'anteprima perde memoria.
Quindi, la mia domanda è questa: se io so che un processo è trapelato ariete tramite un improvviso e inaspettato aumento della impronta kernel_task, perché non si può OS X sapere che qualcosa ha sbagliato andato. Se uccidere Preview ripristina la mia malloc()memoria mancante , perché Darwin non esegue automaticamente la garbage collection per me?
Ho un equivoco fondamentale sul funzionamento della gestione della memoria?
EDIT: (15/9/15)
Ecco una dimostrazione di ciò di cui sto parlando. Prima di tutto, noto un elevato utilizzo della memoria da parte kernel_task(nota che l'anteprima è aperta, appena visibile nella parte inferiore di Activity Monitor, usando 333 MiB di RAM):
Seguendo le utili osservazioni di Ashley di seguito, scopriamo quanto sta usando ogni 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
$
Quindi, non una quantità enorme. La mia macchina ha GPU sia discrete che integrate; i loro driver usano solo pochi MiB di RAM cablata. Nel mio sospetto, uccidiamo l'anteprima e guardiamo cosa succede all'impronta di memoria di kernel_task:
L'anteprima è sparita e l'impronta di memoria del kernel è diminuita drasticamente. Non ci sono ancora prove di un cambiamento nell'uso del kext: l'output del comando sopra è invariato.
Modifica : Bug segnalato come n. 22701036. Sto ancora aspettando una risposta da Apple. Non c'è nulla di particolarmente interessante se si ispeziona il processo in ActivityMonitor, ma forse mi manca qualcosa.
kextstat. La mia comprensione è che se un kext perde, allora i byte allocati e quelli che il kernel sa che sono allocati saranno diversi. In questo caso, l'ho messo lì per dimostrare che non ho un kext che perde - quindi, 2) questo non si verifica quando Anteprima mangia ram. Invece, kernel_taskcresce molto. Proverò a ricreare questo problema e farò una foto :-).
diffcomando stia confrontando le colonneSizee dall'output. Sono d'accordo che si tratta di "memoria allocata", ma non credo che si debba "allocare" (la descrive come "Il numero di byte cablati della memoria del kernel occupata dal kext"). 2) Stai vedendo la discrepanza tra e quando hai il problema con l'anteprima?WiredkextstatSizeWiredman kextstatSizeWired