overhead pour une arène tas vide

Question

Mes outils sont Linux, gcc et pthreads. Lorsque mon programme appelle new/delete à partir de plusieurs threads, et lorsqu'il y a un conflit pour le tas, les arènes sont créées (voir le lien suivant pour la référence http://www.bozemanpass.com/info/linux/malloc/Linux_Heap_Contention.html). Mon programme fonctionne 24x7, et les arènes sont encore en cours de création après 2 semaines. Je pense qu'il pourrait éventuellement y avoir autant d'arènes que de fils. ps (1) montre une consommation de mémoire alarmante, mais je soupçonne que seule une petite partie de celle-ci est réellement mappée.

Quel est le 'overhead' pour une arène vide? (Combien de mémoire par arène est utilisé que si toute l'allocation était confinée au tas traditionnel?)

Y a-t-il un moyen de forcer la création avant les arènes? Y a-t-il un moyen de forcer la destruction des arènes vides?

Answer 1

malloc_state struct (aka mstate, aka descripteur d'arène) ont une taille

glibc-2,2 (256 + 18) * 4 octets = ~ 1 Ko pour mode 32 bits et ~ 2 Ko pour le mode 64 bits. glibc-2.3 (256 + 256/32 + 11 + NFASTBINS) * 4 = ~ 01.01 à 01.02 Ko 32 bits et 64 bits pour KB 02.04 à 02.05

Voir fichier glibc-xxx/malloc/malloc.c, struct malloc_state

Answer 2

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

Le même résultat que je suis pour le mode 32 bits. Le résultat est un peu plus de 1K octets

Answer 3

Destruction des arènes ... Je ne sais pas encore, mais il y a ce texte (brièvement - il dit NON à la possibilité de destruction/mémoire parage) de l'analyse http://www.citi.umich.edu/techreports/reports/citi-tr-00-5.pdf de 2000 (* un peu désuet). Veuillez nommer votre version 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

à l'aide de Tenir compte TCmalloc formulaire google-perftools. Il est juste mieux adapté pour fileté et longue durée applications. Et il est très FAST. Jetez un oeil sur http://goog-perftools.sourceforge.net/doc/tcmalloc.html en particulier sur les graphiques (plus c'est mieux). Tcmalloc est deux fois mieux que ptmalloc.

Answer 5

Dans notre application, le coût principal des arènes multiples était la mémoire "sombre". Mémoire allouée par le système d'exploitation, à laquelle nous n'avons aucune référence.

Le modèle que vous pouvez voir est

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. 

Les grandes allocations sont libérés. Mais l'arène entière à la ligne des hautes eaux de la dernière allocation actuellement active utilise encore VMEM, et les autres threads n'utiliseront pas cette arène à moins qu'ils n'atteignent des conflits dans l'arène principale.

Fondamentalement, c'est un contributeur à la "fragmentation de la mémoire", car il existe plusieurs endroits de la mémoire peut être disponible, mais avoir besoin de développer une arène n'est pas une raison de regarder dans d'autres domaines.Au moins, je pense que c'est la cause, le point est que votre application peut se retrouver avec une plus grande empreinte VM que vous ne le pensez. Cela vous frappe surtout si vous avez un échange limité, puisque, comme vous le dites, la plupart de ceux-ci finissent par être piratés.

Notre application (mémoire affamée) peut avoir 10s pour cent de mémoire "gaspillée" de cette façon, et elle peut vraiment mordre dans certaines situations.

Je ne sais pas pourquoi vous voudriez créer des arènes vides. Si les allocations et les libérations sont dans le même fil que l'un l'autre, alors je pense qu'au fil du temps, vous aurez tendance à tous être dans le même domaine spécifique au thread sans conflit. Il se peut que vous ayez quelques petites touches pendant que vous y arrivez, alors peut-être que c'est une raison.