Optimizar el uso de Haskell GC

memory-management garbage-collection

Question

Estoy ejecutando un programa Haskell de larga vida que se aferra a mucha memoria. Corriendo con +RTS -N5 -s -A25M (tamaño de mi caché L3) veo:

715,584,711,208 bytes allocated in the heap
390,936,909,408 bytes copied during GC
  4,731,021,848 bytes maximum residency (745 sample(s))
     76,081,048 bytes maximum slop
           7146 MB total memory in use (0 MB lost due to fragmentation)

                                  Tot time (elapsed)  Avg pause  Max pause
Gen  0     24103 colls, 24103 par   240.99s   104.44s     0.0043s    0.0603s
Gen  1       745 colls,   744 par   2820.18s   619.27s     0.8312s    1.3200s

Parallel GC work balance: 50.36% (serial 0%, perfect 100%)

TASKS: 18 (1 bound, 17 peak workers (17 total), using -N5)

SPARKS: 1295 (1274 converted, 0 overflowed, 0 dud, 0 GC''d, 21 fizzled)

INIT    time    0.00s  (  0.00s elapsed)
MUT     time  475.11s  (454.19s elapsed)
GC      time  3061.18s  (723.71s elapsed)
EXIT    time    0.27s  (  0.50s elapsed)
Total   time  3536.57s  (1178.41s elapsed)

Alloc rate    1,506,148,218 bytes per MUT second

Productivity  13.4% of total user, 40.3% of total elapsed

¡El tiempo de GC es el 87% del tiempo de ejecución total! Estoy ejecutando esto en un sistema con una gran cantidad de RAM, pero cuando configuré un alto valor de -H , el rendimiento fue peor.

Parece que tanto -H como -A controlan el tamaño de gen 0 , pero lo que realmente me gustaría hacer es aumentar el tamaño de gen 1 . ¿Cuál es la mejor manera de hacer esto?

Answer 1

Como Carl sugirió, debería verificar el código de fugas de espacio. Asumiré que su programa realmente requiere mucha memoria por una buena razón.

El programa gastó 2820.18s haciendo GC mayor. Puede reducirlo reduciendo el uso de memoria (no es un caso según la suposición) o el número de colecciones principales. Tiene mucha RAM libre, por lo que puede probar la option -Ffactor :

 -Ffactor

    [Default: 2] This option controls the amount of memory reserved for
 the older generations (and in the case of a two space collector the size
 of the allocation area) as a factor of the amount of live data. For
 example, if there was 2M of live data in the oldest generation when we
 last collected it, then by default we''ll wait until it grows to 4M before
 collecting it again.

En tu caso, hay ~ 3G de datos en vivo. Por defecto, el GC principal se activará cuando el montón crezca a 6G. Con -F3 se activará cuando el montón crezca hasta 9G, lo que le ahorrará ~ 1000s de tiempo de CPU.

Si la mayoría de los datos en vivo son estáticos (por ejemplo, nunca cambia o cambia lentamente), entonces estará interesado en un montón estable . La idea es excluir los datos de larga vida del GC principal. Se puede lograr, por ejemplo, usando formas compactas normales , aunque todavía no se ha fusionado en GHC.