Speicherverwaltung, Threads - Memory Arenas beschraenken oder nicht?

07/06/2016 - 10:10 von Marc Haber | Report spam
Hallo,

ich bràuchte mal ein wenig Nachhilfe zum Thema Memory Arenas und fasse
vorher zusammen, was ich zusammengesammelt habe.

Recommended reading für den Einstieg:
https://siddhesh.in/posts/malloc-pe...glibc.html
https://siddhesh.in/posts/back-to-t...ation.html

tl;dr, zusammengefasst:
Die glibc versucht, Speicher in eher größeren Brocken vom Kernel
anzufordern und teilt diese angeforderten Speicherblöcke in "Arenas"
auf. Für diesen Artikel interessant sind nur Speicherblöcke, die mit
mmap() angefordert werden.

Für jeden neuen Thread wird eine neue Speicherarena angefordert, damit
man sich (im Normalfall) keine Locks zwischen den einzelnen Threads
einfàngt. Dabei gibt es eine Obergrenze; auf 64-bit-Systemen liegt
diese Grenze beim achtfachen der Coreanzahl. Auf einem Quadcore
bekommt ein gethreadeter Prozess also maximal 32 Memory Arenas (oder
ist das eine systemweite Beschrànkung? Dafür wirkt sie mir ein wenig
klein). Ab dem 33sten Thread muss halt doch in einer bereits für einen
anderen Thread angelegten Memory Arena nach Speicher gesucht werden.

Siddhesh schreibt allerdings auch, dass die Allokation einer neuen
Memory Arena lediglich _Adressraum_ belegt und der Kernel nicht
gebeten wird, diesen Adressraum mit virtuellem oder gar physikalischem
Speicher zu belegen.

In der Praxis führt das dazu, dass in den Statistiktools gethreadete
Prozesse mit einer absurd hohen Speichergröße geführt werden, obwohl
die Resident Set Size durchaus in realistischem Rahmen liegt. Dies
wiederum hat in zahlreichen Supportforen zu dem Ergebnis gefühlt, dass
es üblich ist, die Anzahl der Memory Arenas durch Setzen der
Environmentvariablen MALLOC_ARENA_MAX zu begrenzen, was natürlich
dafür sorgt, dass die Threads schneller gegenseitig locks setzen
müssen wenn sie Speicher allokieren wollen.

Auf https://devcenter.heroku.com/articl...memory-use
geht man sogar so weit, dass man eine Tabelle aufstellt, aus der der
geneigte Leser ablesen kann, dass die RSS mit der Beschrànkung der
Arena-Anzahl ebenfalls heruntergeht. Da ich persönlch die Erklàrungen
von Siddhesh für fundierter halte, tendiere ich zu der Aussage, dass
die Angaben auf der Heroku-Webseite nur für das konkrete Produkt, also
Heruko auf Cedar (was auch immer das ist) zutreffen und sich das
Produkt halt mit seiner Speicherbelgegung zurückgeht wenn weniger
Arenas zur Verfügung stehen. Die Performance der Applikation geht
übrigens durchaus messbar zurück.

Mich würde jetzt interessieren, ob ich mit meinen Gedanken, die
weitgehend von der wirklichen Funktion der Speicherallokation
unbeeinflusst sind (ich versuche gar nicht erst mich da in der Tiefe
einzulesen, das ist ja eine Wissenschaft für sich), richtig liege oder
ob es wirklich sinn voll ist, MALLOC_ARENA_MAX manuell zu beschrànken.

In meinem aktuellen Projekt sagen die Applikations-Admins, dass ihnen
ohne die Beschrànkung der Arena-Anzahl der Speicher vollàuft und
danach der Out-of-Memory-Killer zuschlàgt. Meine Einschàtzung ist,
dass dies von der Arenaanzahl unabhàngig ist, da auch bei weniger
Arenen so viel virtueller Speicher belegt wird wie die Applikation
anfordert und die Anzahl der Arenen nur die Größe des belegten
Adressraums beeinflusst. Liege ich da richtig?

Spielt in das Thema hinein, dass die Applikation hier in Containern
làuft, d.h. die Applikation potenziell zwar die volle Anzahl Cores,
aber nur einen Teil des Speichers/Adressraumes sieht?

Mag mich da mal jemand erleuchten? Dankeschön!

Grüße
Marc
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
 

Lesen sie die antworten

#1 Bernd Waterkamp
07/06/2016 - 18:54 | Warnen spam
Marc Haber schrieb:

Spielt in das Thema hinein, dass die Applikation hier in Containern
làuft, d.h. die Applikation potenziell zwar die volle Anzahl Cores,
aber nur einen Teil des Speichers/Adressraumes sieht?



Wenn es Java in einem Docker-Container sein sollte, ist das vielleicht
einfach ein Docker-Bug: https://github.com/docker/docker/issues/15020
Da erwàhnt zumindest jemand, das MALLOC_ARENA_MAX=4 OOM verhindert.

HTH,
Bernd

Ähnliche fragen