Zerfällt freier Speicher durch ständiges Allozieren und Freigeben in kleine Stücke, belegt der Prozess viel mehr Speicher, als er tatsächlich nutzt.
Warum Viele Threads allozieren und geben über lange Zeit Speicherblöcke unterschiedlicher Größe frei → Folge Freier Speicher in kleinen Stücken verstreut, kann nicht ans OS zurückgegeben werden, Verbrauch steigt wie bei einem Leck immer weiter → Auf dem Bildschirm Je länger der Server läuft, desto langsamer wird er durch Swap und Speichermangel, bis er zwangsweise beendet wird
Speicher-Pools pro Blockgröße und fragmentierungsresistente Allokatoren (jemalloc, mimalloc u. a.) einsetzen.
Im Graphen
Langsamer Anstieg · Prozessspeicher (RSS)
Wo nachsehen
Zwei Server mit demselben Build starten, nur bei einem die Zahl der glibc-Arenen per Umgebungsvariable MALLOC_ARENA_MAX senken oder auf einen anderen Allokator wie jemalloc wechseln, dann einige Tage lang RSS aus pidstat -r vergleichen
Spricht dafür
Bei ähnlicher Spieler- und Objektzahl hört der RSS-Anstieg nur beim geänderten Server auf oder fällt deutlich geringer aus
Spricht dagegen
Steigt nach dem Allokatorwechsel genauso: nie freigegebener Speicher (mem-leak)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Der Verlauf sieht aus wie bei einem Speicherleck, doch die Heap-Analyse findet keine Leckstelle. Beim Standard-Allokator von Linux (glibc) ist das Problem auf Servern mit vielen Threads besonders ausgeprägt. Schon ein Wechsel des Allokators kann den Verbrauch deutlich senken.
Quellen
mallopt(3) — Linux manual pageLinux man-pages glibc malloc legt zur Verringerung von Thread-Contention Arenen bis zu einem Vielfachen der CPU-Anzahl an, mehr Arenen bedeuten mehr Speicherverbrauch (Begrenzung mit M_ARENA_MAX, auch per Umgebungsvariable MALLOC_ARENA_MAX einstellbar)
jemalloc memory allocatorjemalloc Allgemeine malloc-Implementierung mit Schwerpunkt auf Vermeidung von Fragmentierung und skalierbarer Nebenläufigkeit