Ist die Anzahl der NUMA-Knoten immer gleich Sockets?

28293
Nan Xiao

Ich habe lscpuzwei Server-Konfigurationen überprüft:

[root@localhost ~]# lscpu Architecture: x86_64 ...... Core(s) per socket: 1 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 26 

Das andere:

[root@localhost Packages]# lscpu Architecture: x86_64 ..... Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 45 

Ich frage mich also, ob die Anzahl der NUMA-Knoten tatsächlich immer Sockets entspricht. Gibt es ein Beispiel, bei dem sie nicht gleich sind?

11

2 Antworten auf die Frage

17
Marki555

Warum wundern Sie sich über die Anzahl der NUMA-Knoten? Der wichtige Teil ist die NUMA-Topologie, die besagt, wie diese "Knoten" miteinander verbunden sind.

Ich habe einige Systeme geprüft, darunter ein 8-Sockel-System (10-Core-CPUs), das aus 4 miteinander verbundenen 2-Sockel-Blades (Hitachi Compute Node 2000) besteht. Auch hier entspricht die Anzahl der NUMA-Knoten der Anzahl der CPU-Sockets (8). Dies hängt von der CPU-Architektur ab, hauptsächlich vom Speicherbus-Design.

Der gesamte NUMA (nicht einheitlicher Speicherzugriff) definiert, wie jede logische CPU auf jeden Teil des Speichers zugreifen kann. Wenn Sie über ein Socket-System verfügen, verfügt jede CPU (Socket) über einen eigenen Speicher, auf den sie direkt zugreifen kann. Es muss jedoch auch auf Speicher in dem anderen Socket zugreifen können - und dies erfordert natürlich mehr CPU-Zyklen als der Zugriff auf lokalen Speicher. NUMA-Knoten geben an, welcher Teil des Systemspeichers für welche CPU lokal ist. Sie können über mehrere Topologieebenen verfügen, z. B. im Fall eines HP Superdome-Systems (das Intel Itanium2-CPUs verwendet), Sie haben lokalen CPU-Socketspeicher, dann Speicher auf verschiedenen Sockets in derselben Zelle und dann Speicher in anderen Zellen (die über die höchste Latenzzeit).

Sie können den NUMA in Ihrem System so konfigurieren, dass er sich so verhält, dass er für Ihre Workload die bestmögliche Leistung bietet. Sie können beispielsweise zulassen, dass alle CPUs auf den gesamten Speicher zugreifen oder nur auf den lokalen Speicher zugreifen. Dadurch ändert sich, wie der Linux-Scheduler Prozesse auf die verfügbaren logischen CPUs verteilt. Wenn Sie viele Prozesse benötigen, die nicht viel Speicher benötigen, kann die Verwendung von nur lokalem Speicher von Vorteil sein. Wenn Sie jedoch über große Prozesse verfügen (Oracle-Datenbank mit gemeinsam genutztem Speicher), ist die Verwendung des gesamten Speichers unter allen CPU-Speichern möglicherweise besser.

Sie können Befehle wie numastatoder verwenden numactl --hardware, um den NUMA-Status in Ihrem System zu überprüfen. Hier sind Informationen von dieser 8-Sockel-Maschine:

hana2:~ # lscpu Architecture: x86_64 CPU(s): 160 Thread(s) per core: 2 Core(s) per socket: 10 CPU socket(s): 8 NUMA node(s): 8 NUMA node0 CPU(s): 0-19 NUMA node1 CPU(s): 20-39 NUMA node2 CPU(s): 40-59 NUMA node3 CPU(s): 60-79 NUMA node4 CPU(s): 80-99 NUMA node5 CPU(s): 100-119 NUMA node6 CPU(s): 120-139 NUMA node7 CPU(s): 140-159  hana2:~ # numactl --hardware available: 8 nodes (0-7) node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 node 0 size: 130961 MB node 0 free: 66647 MB node 1 cpus: 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 node 1 size: 131072 MB node 1 free: 38705 MB node 2 cpus: 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 node 2 size: 131072 MB node 2 free: 71668 MB node 3 cpus: 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 node 3 size: 131072 MB node 3 free: 47432 MB node 4 cpus: 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 node 4 size: 131072 MB node 4 free: 68458 MB node 5 cpus: 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 node 5 size: 131072 MB node 5 free: 62218 MB node 6 cpus: 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 node 6 size: 131072 MB node 6 free: 68071 MB node 7 cpus: 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 node 7 size: 131008 MB node 7 free: 47306 MB node distances: node 0 1 2 3 4 5 6 7 0: 10 21 21 21 21 21 21 21 1: 21 10 21 21 21 21 21 21 2: 21 21 10 21 21 21 21 21 3: 21 21 21 10 21 21 21 21 4: 21 21 21 21 10 21 21 21 5: 21 21 21 21 21 10 21 21 6: 21 21 21 21 21 21 10 21 7: 21 21 21 21 21 21 21 10 

Dort können Sie sehen, wie viel Speicher in jedem NUMA-Knoten (CPU-Socket) vorhanden ist und wie viel davon belegt und frei ist.

Der letzte Abschnitt zeigt die NUMA-Topologie - sie zeigt die "Entfernungen" zwischen einzelnen Knoten in Bezug auf Speicherzugriffslatenzen (die Zahlen sind nur relativ, sie geben keine Zeit in ms oder irgendetwas an). Hier können Sie sehen, dass die Latenz zum lokalen Speicher (Knoten 0, der auf den Speicher in 0 zugreift, Knoten 1 in 1, ...) 10 ist, während die Remote-Latenz (Knoten, die auf den Speicher eines anderen Knotens zugreift) 21 ist. Dieses System besteht jedoch aus 4 einzelnen Bei Blades ist die Latenz für unterschiedliche Sockel auf demselben Blade oder einem anderen Blade gleich.

Interessantes Dokument über NUMA ist auch im RedHat-Portal .

2
user3135484

Nein. Die Anzahl der NUMA-Knoten entspricht nicht immer der Anzahl der Sockets. Ein AMD Threadripper 1950X hat beispielsweise 1 Sockel und 2 NUMA-Knoten, während ein duales Intel Xeon E5310-System 2 Sockel und 1 NUMA-Knoten anzeigen kann.