11 votos

¿Por qué la memoria filtrada aparece malloqueada en kernel_task y por qué OS X no puede recogerla de la basura?

Anteriormente me han dicho que una señal de que alguna aplicación tiene una fuga de memoria es que kernel_task tiene una gran huella de memoria, normalmente del orden de los gigabytes. Si un error kext estuviera causando este uso de memoria, esperaríamos ver una discrepancia entre la memoria asignada y la que se espera que se asigne, es decir

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

devolvería algo más que las palabras 'Wired' y 'Name'.

Mientras escribía mi tesis, me he dado cuenta de que cambiar un pdf mientras está abierto en Vista Previa a menudo hace que ocurran cosas malas: ocasionalmente, el uso de memoria de kernel_task puede crecer hasta unos ocho gigabytes, o más. Si mato la vista previa, vuelve a la normalidad, al instante . Así que, obviamente, algo está mal - y el Preview está perdiendo memoria bajo estas condiciones.

Entonces, mi pregunta es la siguiente: si I saber que un proceso ha filtrado ram a través de un aumento repentino e inesperado de la huella de kernel_task ¿Por qué no puede OS X saber que algo ha ido mal. Si al matar la vista previa se restablece mi malloc() 'd memoria, por qué no lo hace ¿Darwin hace la recolección de basura automáticamente por mí?

¿Tengo un malentendido fundamental sobre cómo funciona la gestión de la memoria?

EDITAR: (15/9/15)

He aquí una demostración de lo que estoy hablando. En primer lugar, noto un alto uso de memoria por parte de kernel_task (nota La vista previa está abierta, sólo visible en la parte inferior del monitor de actividad, utilizando 333 MiB de ram):

High kernel memory usage

Siguiendo los útiles comentarios de Ashley a continuación, averigüemos cuánto consume cada 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
$

Por lo tanto, no es una cantidad enorme. Mi máquina tiene tanto GPUs discretas como integradas; sus controladores sólo utilizan unos pocos MiB de ram cableada. Siguiendo mi corazonada, matemos a Vista Previa, y veamos qué pasa con la huella de memoria de kernel_task :

Killing preview helps things

La vista previa ha desaparecido, y la huella de memoria del kernel se ha reducido drásticamente. Todavía no hay evidencia de un cambio en el uso de kext: la salida del comando anterior no ha cambiado.

Editar : Bug reportado como No. 22701036. Todavía estoy esperando una respuesta de Apple. No hay nada particularmente interesante si se inspecciona el proceso en ActivityMonitor, pero tal vez me estoy perdiendo algo.

6voto

Steve Evans Puntos 155

El núcleo de OS X no se recolecta la basura; la función de IOKit libkern C++ Runtime requiere que los desarrolladores gestionen su propia memoria.

Gestión de la memoria del Mac

Desde ¿Cómo funciona la gestión de la memoria en Mac OS X?

Apple documenta los niveles más bajos de la Núcleo Mach y el subsistema de memoria virtual bastante bien en la web como parte de su documentación para desarrolladores.

Desde que ese núcleo fue desarrollado por la Universidad Carnegie Mellon , puede encontrar docenas de papeles describiéndola con bastante facilidad.

Otras fuentes

Recogida de basura

La recolección de basura existe en la capa de usuario o de aplicación. Incluso en esta capa, la recolección de basura sólo ayuda si la aplicación ha liberado todas las demandas de la memoria. Una dependencia circular puede anular la recogida de basura. La recolección de basura es un área de investigación en evolución y difícil de acertar .

Informar de errores y fugas de memoria

Los errores dentro de OS X tendrán fugas de memoria. Dado el tamaño de la base de código, esto es casi seguro.

Por favor, informar de los errores reproducibles directamente a Apple . Cada informe de error ayuda y tal vez tu ejemplo sea el que ayude a los ingenieros de Apple a localizar la causa.

4voto

Ashley Puntos 2261

Esta es mi suposición, asumiendo que tu Mac tiene una GPU integrada (por ejemplo, Intel Iris Graphics).

Cuando tienes tu tesis abierta en Vista Previa, la memoria de la tarjeta gráfica se utiliza para mantener la imagen ("textura") de la ventana de Vista Previa, y quizás también algunas páginas de la tesis fuera de la pantalla pero descodificadas.

En el caso de las tarjetas gráficas integradas, la memoria de vídeo se encuentra en realidad (¿parcialmente?) en la RAM del sistema, que se comparte entre la CPU y la GPU. En algunas tarjetas gráficas integradas, la cantidad de RAM del sistema utilizada se asigna dinámicamente (véase Apple HT204349 ).

Supongo que estás viendo intermitentemente un error en el controlador de la tarjeta gráfica y/o en Vista Previa, que no está liberando la memoria del sistema correctamente cuando Vista Previa recarga tu PDF de tesis. (Sin embargo, este error es mitigado por OS X / el controlador de liberar correctamente la memoria cuando se cierra la vista previa).

Puedes probar a mirar la salida de kextstat y ver si los números del Size aumento de la columna cuando se experimenta el problema. Mi teoría es que el aumento de 8 GB que mencionas se debe al controlador de la tarjeta gráfica.

El siguiente comando (de un comentario en esta respuesta relacionada e interesante ) ordena la salida de kextstat para que sea más fácil ver qué kext está usando más memoria (aunque hay que tener en cuenta que esto ordena por el Wired Hay un encantamiento similar, más simple, en esta respuesta con una explicación si quiere modificar esto).

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

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X