haskell - metatags - ¿Cómo debo interpretar la salida del generador de perfiles de ghc?

meta tags ejemplos

Question

Tengo un proceso de servidor implementado en haskell que actúa como un db en memoria simple. Los procesos del cliente pueden conectarse y luego agregar y recuperar datos. El servicio utiliza más memoria de la que esperaba, y estoy intentando averiguar por qué.

La métrica más cruda que tengo es linux "top". Cuando comienzo el proceso, veo un tamaño de imagen "VIRT" de ~ 27MB. Después de ejecutar un cliente para insertar 60,000 elementos de datos, veo un tamaño de imagen de ~ 124MB.

Ejecutando el proceso para capturar estadísticas de GC (+ RTS -S), veo inicialmente

Alloc Copied Live GC GC TOT TOT Page Flts
bytes bytes bytes user elap user elap
28296 8388 9172 0.00 0.00 0.00 0.32 0 0 (Gen: 1)

y al agregar los elementos de 60k veo que los bytes en vivo crecen sin problemas para

 ...
532940 14964 63672180 0.00 0.00 23.50 31.95 0 0 (Gen: 0)
532316 7704 63668672 0.00 0.00 23.50 31.95 0 0 (Gen: 0)
530512 9648 63677028 0.00 0.00 23.50 31.95 0 0 (Gen: 0)
531936 10796 63686488 0.00 0.00 23.51 31.96 0 0 (Gen: 0)
423260 10047016 63680532 0.03 0.03 23.53 31.99 0 0 (Gen: 1)
531864 6996 63693396 0.00 0.00 23.55 32.01 0 0 (Gen: 0)
531852 9160 63703536 0.00 0.00 23.55 32.01 0 0 (Gen: 0)
531888 9572 63711876 0.00 0.00 23.55 32.01 0 0 (Gen: 0)
531928 9716 63720128 0.00 0.00 23.55 32.01 0 0 (Gen: 0)
531856 9640 63728052 0.00 0.00 23.55 32.02 0 0 (Gen: 0)
529632 9280 63735824 0.00 0.00 23.56 32.02 0 0 (Gen: 0)
527948 8304 63742524 0.00 0.00 23.56 32.02 0 0 (Gen: 0)
528248 7152 63749180 0.00 0.00 23.56 32.02 0 0 (Gen: 0)
528240 6384 63756176 0.00 0.00 23.56 32.02 0 0 (Gen: 0)
341100 10050336 63731152 0.03 0.03 23.58 32.35 0 0 (Gen: 1)
5080 10049728 63705868 0.03 0.03 23.61 32.70 0 0 (Gen: 1)

Esto parece decirme que el montón tiene ~ 63MB de datos en vivo. Esto podría ser coherente con los números de arriba, para el momento en que agregue espacio de pila, espacio de código, sobrecarga de GC, etc.

Así que intenté usar el generador de perfiles del montón para averiguar qué conforma este 63MB. Los resultados son confusos. Ejecutando con "+ RTS -h", y mirando el archivo hp generado, la última y más grande instantánea tiene:

containers-0.3.0.0:Data.Map.Bin 1820400
bytestring-0.9.1.7:Data.ByteString.Internal.PS 1336160
main:KV.Store.Memory.KeyTree 831972
main:KV.Types.KF_1 750328
base:GHC.ForeignPtr.PlainPtr 534464
base:Data.Maybe.Just 494832
THUNK 587140

Todos los otros números en la instantánea son mucho más pequeños que esto. Al agregar estos, el uso máximo de memoria es de ~ 6MB, como se refleja en la salida del gráfico:

¿Por qué esto es inconsistente con los bytes en vivo como se muestra en las estadísticas de GC? Es difícil ver cómo mis estructuras de datos podrían requerir 63 MB, y el generador de perfiles dice que no lo son. ¿A dónde va la memoria?

Gracias por cualquier consejo o consejos sobre esto.

Tim

Answer 1

Debe usar, por ejemplo, hp2ps para obtener una vista gráfica de lo que está sucediendo. Mirar el archivo hp en bruto es difícil.

Answer 2

No todo está incluido en el perfil por defecto, por ejemplo, hilos y pilas. Pruebe con +RTS -xT .

Answer 3

Tengo una teoría. Mi teoría es que su programa está utilizando mucho como ByteStrings . Mi teoría es que debido a que el contenido principal de ByteStrings es ByteStrings , no se muestran al perfilar. Por lo tanto, podría quedarse sin almacenamiento sin que el contenido más grande de su montón aparezca en el gráfico de perfiles.

Para empeorar las cosas, cuando toma subcadenas de ByteStrings , retienen el puntero al bloque de memoria asignado originalmente. Por lo tanto, incluso si intenta almacenar solo una pequeña parte de algunas ByteString , podría terminar reteniendo la totalidad de las ByteString asignadas originalmente y esto no aparecerá en su perfil de pila.

Esa es mi teoría de todos modos. No conozco suficientes datos sobre cómo funciona el generador de perfiles de GHC ni sobre cómo se implementan los ByteStrings para saberlo con certeza. Tal vez alguien más pueda intervenir y confirmar o disputar mi teoría.

Edit2: tibbe observa que el búfer utilizado por ByteString s está ByteString . Por lo tanto, si está asignando / liberando muchos Bytestring pequeños, puede fragmentar su montón, lo que significa que se queda sin un montón utilizable con la mitad sin asignar.

Edición: JaffaCake me dice que a veces el generador de perfiles del montón no muestra la memoria asignada por ByteStrings.