overhead per un'area arena vuota

Question

I miei strumenti sono Linux, gcc e pthreads. Quando il mio programma chiama new/delete da diversi thread, e quando c'è conflitto per l'heap, vengono create le arena (vedere il seguente link per il riferimento http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html). Il mio programma funziona 24 ore su 24, 7 giorni su 7 e le arene vengono ancora create occasionalmente dopo 2 settimane. Penso che alla fine ci possano essere tante arene quante discussioni. ps (1) mostra un allarmante consumo di memoria, ma sospetto che solo una piccola porzione di esso sia effettivamente mappata.

Che cos'è il sovraccarico di un'arena vuota? (Quanta più memoria per arena viene usata che se tutta l'allocazione fosse confinata all'heap tradizionale?)

C'è un modo per forzare la creazione prima delle n arene? C'è un modo per forzare la distruzione delle arene vuote?

Answer 1

struct malloc_state (alias mstate, alias descrittore Arena) ha formato

glibc-2,2 (256 + 18) * 4 byte = ~ 1 KB per la modalità a 32 bit e ~ 2 KB per modalità a 64 bit. glibc 2.3- (256 + 256/32 + 11 + NFASTBINS) * 4 = ~ 1.1-1.2 KB a 32 bit e 64 bit per 2.4-2.5 KB

Vedi glibc-xxx file/malloc/malloc.c, struct malloc_state

Answer 2

da malloc.c (glibc 2.3.5) linea 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.) 
*/ 

Lo stesso risultato che ho ottenuto per la modalità a 32 bit. Il risultato è un po 'più di 1 Kbyte

Answer 3

Distruzione di arene ... Non lo so ancora, ma c'è una tale testo (per breve tempo - si dice NO alla possibilità di distruzione/memoria di rifilatura) dall'analisi http://www.citi.umich.edu/techreports/reports/citi-tr-00-5.pdf del 2000 (* un po 'obsoleto). Si prega di nominare la versione di 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

considerare l'utilizzo di TCmalloc forma google-perftools. È semplicemente più adatto per applicazioni con threading e longeva. Ed è molto FAST. Dai uno sguardo allo http://goog-perftools.sourceforge.net/doc/tcmalloc.html soprattutto sulla grafica (più alto è meglio). Tcmalloc è due volte migliore rispetto a ptmalloc.

Answer 5

Nella nostra applicazione il costo principale di più arene è stata la memoria "oscura". Memoria allocata dal sistema operativo, a cui non abbiamo alcun riferimento.

Il modello che si può vedere è

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. 

grandi allocazioni vengono liberate. Ma l'arena intera al limite massimo dell'ultima allocazione attualmente attiva sta ancora utilizzando VMEM, e altri thread non useranno questa arena a meno che non raggiungano la contesa nell'arena principale.

Fondamentalmente è un contributore alla "frammentazione della memoria", dal momento che ci sono più posti in cui la memoria può essere disponibile, ma la necessità di far crescere un'arena non è un motivo per guardare in altre arene.Almeno penso che sia la causa, il punto è che la tua applicazione può finire con un'impronta VM più grande di quanto pensi che dovrebbe avere. Questo ti colpisce soprattutto se hai uno swap limitato, dal momento che come dici tu la maggior parte di questo finisce fuori di testa.

La nostra applicazione (che ha fame di memoria) può avere il 10% della memoria "sprecata" in questo modo e in alcune situazioni può davvero azzuffarsi.

Non sono sicuro del motivo per cui si desidera creare arene vuote. Se le allocazioni e le frees sono nello stesso thread l'una dell'altra, allora penso che nel tempo tenderete a essere tutti nella stessa arena specifica per thread senza contesa. Potresti avere dei piccoli blip mentre sei lì, quindi forse è un buon motivo.