sobrecarga para un montón de montón vacío

Question

Mis herramientas son Linux, gcc y pthreads. Cuando mi programa llama a new/delete desde varios hilos, y cuando hay contención para el montón, se crean 'arena's (mira el siguiente enlace para referencia http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html). Mi programa se ejecuta las 24 horas, los 7 días de la semana, y las arenas todavía se crean ocasionalmente después de 2 semanas. Creo que eventualmente puede haber tantas arenas como hilos. ps (1) muestra un consumo de memoria alarmante, pero sospecho que solo una pequeña parte está mapeada.

¿Cuál es la 'sobrecarga' para una arena vacía? (¿Cuánta memoria más por arena se usa que si toda la asignación se limitó al montón tradicional?)

¿Hay alguna manera de forzar la creación antes de n arenas? ¿Hay alguna manera de forzar la destrucción de arenas vacías?

Answer 1

struct malloc_state (aka mstate, también conocido como descriptor de arena) tienen tamaño

glibc-2,2 (256 + 18) * 4 bytes = ~ 1 KB para el modo de 32 bits y ~ 2 KB para el modo de 64 bits. glibc-2.3 (256 + 256/32 + 11 + NFASTBINS) * 4 = ~ 1,1-1,2 KB de 32 bits y de 64 bits 2,4-2,5 KB para

Ver fichero glibc-xxx/malloc/malloc.c, struct malloc_state

Answer 2

de malloc.c (glibc 2.3.5) de la línea 1546

/* 
    -------------------- Internal data structures -------------------- 
    All internal state is held in an instance of malloc_state defined 
    below. 
... 
    Beware of lots of tricks that minimize the total bookkeeping space 
    requirements. **The result is a little over 1K bytes** (for 4byte 
    pointers and size_t.) 
*/ 

El mismo resultado como llegué para el modo de 32 bits. El resultado es un poco más de 1 KB

Answer 3

Destrucción de arenas ... No sé aún, pero hay tal texto (por poco tiempo - dice NO a la posibilidad de destrucción de memoria/recorte) del análisis http://www.citi.umich.edu/techreports/reports/citi-tr-00-5.pdf de 2000 (* un poco desactualizado). Por favor, nombre su versión glibc.

Ptmalloc maintains a linked list of subheaps. To re- 
duce lock contention, ptmalloc searchs for the first 
unlocked subheap and grabs memory from it to fulfill 
a malloc() request. If ptmalloc doesn’t find an 
unlocked heap, it creates a new one. This is a simple 
way to grow the number of subheaps as appropriate 
without adding complicated schemes for hashing on 
thread or processor ID, or maintaining workload sta- 
tistics. However, there is no facility to shrink the sub- 
heap list and nothing stops the heap list from growing 
without bound. 

Answer 4

considerar el uso de TCmalloc formulario de Google-perftools. Simplemente mejor para roscado y long-living aplicaciones. Y es muy FAST. Eche un vistazo en http://goog-perftools.sourceforge.net/doc/tcmalloc.html especialmente en gráficos (más alto es mejor). Tcmalloc es dos veces mejor que ptmalloc.

Answer 5

En nuestra aplicación, el costo principal de varias arenas ha sido la memoria "oscura". Memoria asignada por el sistema operativo, a la que no tenemos ninguna referencia.

El patrón se puede ver es

Thread X goes goes to alloc, hits a collision, creates a new arena. 
Thread X makes some large allocations. 
Thread X makes some small allocation(s). 
Thread X stops allocating. 

grandes asignaciones son liberados. Pero el arena completa en la marca de agua máxima de la última asignación actualmente activa todavía está utilizando VMEM, y otros hilos no utilizarán esta arena a menos que golpeen la contención en la arena principal.

Básicamente es un colaborador de la "fragmentación de la memoria", ya que hay muchos lugares donde la memoria puede estar disponible, pero la necesidad de hacer crecer un estadio no es una razón para buscar en otros ámbitos.Al menos creo que esa es la causa, el punto es que su aplicación puede terminar con una huella de VM más grande de lo que cree que debería tener. Esto sobre todo te golpea si tienes un intercambio limitado, ya que como dices, la mayoría de esto termina paginado.

Nuestra aplicación (hambrienta de memoria) puede tener un 10% del porcentaje de memoria "desperdiciada" de esta manera, y realmente puede morder en algunas situaciones.

No estoy seguro de por qué querría crear arenas vacías. Si las asignaciones y las liberaciones están en el mismo hilo que las demás, creo que con el tiempo tenderás a que todas ellas estén en la misma arena específica de subprocesos sin contención. Es posible que tengas algunos pequeños puntos mientras llegas allí, así que quizás esa sea una razón.