Warum soll das nichts mit den Speicherkanälen zu tun haben?
Weil die Problematik die Anzahl der NUMA Nodes ist - nicht (TR like) der Aufbau...
Keine Ahnung worauf du hinaus willst - AMD hat das Thema komplett beerdigt. Das Beste, was potentiellen Kunden überhaupt passieren konnte.
Einer der größte Kritikpunkte seit G34 ist endlich vom Tisch. Da gibts eigentlich nichts dran auszusetzen und vor allem ist es unnötig die Existenz der Probleme zu leugnen, so wie du das hier gerade versuchst.
Beim Eypc hat jeder Numa Node seine eigene zwei Speicherbänke. Somit hat meine keine Probleme, solange die maximale Speicherbelegung pro Numa Node nicht überschritten wird. Wenn 256 GB installiert sind, kann pro Numa Node 64 GB verwendet werden.
Siehst du - das ist das Problem. Der besser gesagt, das ist ein größerer Teil des NUMA Problems. Der zweite große Problempunkt ist die Anzahl der Cores/Threads pro NUMA Node mit lokalem Speicher. Wenn wie in deinem Fall beim 7301 16C/32T installiert sind, kann pro NUMA Node 4C/8T verwendet werden. Was mach ich mit VMs, die mit 16 oder 32GB auskommen, aber 8x vCPUs wollen? (Terminal Server oder VDI Clients bspw. wären eher CPU lastig bei aktiver Nutzung) Mit nur einem Node (wie Epyc 2 oder den Xeons) hättest du das nicht. Exakt das beschreibt die Problematik, die Epyc 1 massiv Wind aus den Segeln genommen hat. Mit Epyc 2 wie gesagt, kein Problem...
Nö, ansonsten hätte man bei CFD massive Probleme, das Epyc System ist schneller:
AMD Epyc CFD benchmarks with Ansys Fluent -- CFD Online Discussion Forums
Auch hier verstehst du scheinbar das Problem nicht. Was der CFD Einwand bezwecken soll erschließt sich mir nicht - niemand sprach von "schneller" oder "langsamer". Zumal schneller/langsamer als was genau?
Ich sagte, das die Fabric schmal ist. Und das ist nachweislich der Fall, da die theoretische maximal Bandbreite gerade so ausreicht um vollen RAM Durchsatz beim 8-Kanal SI zu gewährleisten. Kommt dann noch Inter DIE Traffic für die Cores, Cachezugriffe und dergleichen dazu sowie PCIe Traffic, kannst du zusehen, wie der Spaß "einschläft"... Glaubst du nicht? Teste es selbst. Du hast ja offenbar nen Epyc stehen...
Ja, weil man voher schon weiß wie viele VM usw. man ungefähr verwendet.
Das mag sein, aber was bringt es dir außer den Vorteil, diesen eigentlich unnötigen Workaround anwenden zu können?
Idealerweise ist das verwendete System in Sachen Belastung flexibel. Sodass man nur so viel Ressourcen kaufen muss um das abzudecken, was an Bedarf da ist. Ein Xeon ist das, ein Epyc 2 auch... Du kannst fast bedenkenlos Threads und Speicherbedarf hoch und runter skalieren, wie du lustig bist oder deine Anforderungen es definieren. Das ist der Grund, warum das NUMA Problem nichts mit der Anzahl der Speicherkanäle zu tun hat, weil es unabhängig des genutzten Produktes im selben Maße zutrifft.
Ich für meinen Teil sehe absolut keinen Sinn darin, Speicher bis teils Faktor 4 über den Bedarf zu erstehen, wo gerade im VM Umfeld der RAM idR der teuerste Posten ist. Zudem fressen einen die Lizenzen in Sachen pro Core Lizensierung nicht selten die Haare vom Kopf, nur weil man da bis Faktor 4 über den Bedarf gehen soll - wozu sollte man das wollen??
