Nutzt ein Prozess auf einem Server mit zwei CPUs Speicher, der an der anderen CPU hängt, werden die Zugriffe langsamer.
Warum Threads und ihr Speicher liegen auf verschiedenen CPU-Sockeln → Folge Speicherzugriffe werden langsamer (je nach Hardware um das 1,5- bis 2-Fache) → Auf dem Bildschirm Gleiche Ausstattung, aber Leistungsunterschiede von Prozess zu Prozess
Prozesse und ihren Speicher an einen Sockel binden (numactl), bei zwei Sockeln je Sockel eigene Spielserverprozesse betreiben.
Im Graphen
Nur einzelne Ausreißer · Tick-Zeit pro Prozess, Speicher pro Knoten
Wo nachsehen
Mit numastat -p PID prüfen, auf welchem NUMA-Knoten der Speicher des Spielserverprozesses liegt und ob numa_miss und other_node in numastat steigen, dann mit dem Knoten der CPU vergleichen, auf der der Prozess läuft
Spricht dafür
Nur bei den langsamen Prozessen liegt der Großteil des Speichers auf einem anderen Knoten als die CPU, auf der sie laufen, und nach einem Neustart mit per numactl an einen Knoten gebundener CPU und gebundenem Speicher verschwindet der Unterschied
Spricht dagegen
Gleiche Knotenverteilung wie bei den schnellen Prozessen, trotzdem langsam: andere Ursache wie Noisy Neighbor, CPU-Throttling oder Last dieses Prozesses
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
What is NUMA?Linux kernel Speicher in derselben Zelle ist schneller und hat mehr Bandbreite, Zugriffe auf Speicher in einer anderen (entfernten) Zelle sind langsamer
numactl(8) — Linux manual pagenumactl --cpunodebind und --membind binden CPU und Speicher eines Prozesses an bestimmte NUMA-Knoten
numastat(8) — Linux manual pagenumactl Zähler numa_miss (Allokation auf einem anderen als dem gewünschten Knoten) und other_node (Allokation auf diesem Knoten durch einen Prozess, der auf einem anderen Knoten läuft), -p zeigt den Speicher eines Prozesses pro Knoten