Ich habe lscpudie Konfiguration von zwei Servern ü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
Daher frage ich mich, ob die Anzahl der NUMA-Knoten tatsächlich immer der Anzahl der Sockets entspricht. Gibt es ein Beispiel, bei dem sie nicht gleich sind?
Antwort1
Warum wundern Sie sich über die Anzahl der NUMA-Knoten? Wichtig ist die NUMA-Topologie, die angibt, wie diese „Knoten“ verbunden sind.
Ich habe einige Systeme geprüft, darunter ein 8-Sockel-System (10-Core-CPUs), das aus 4 miteinander verbundenen 2-Sockel-Blades besteht (Hitachi Compute Node 2000). Auch hier ist die Anzahl der NUMA-Knoten gleich der Anzahl der CPU-Sockel (8). Dies hängt von der CPU-Architektur ab, hauptsächlich von der Speicherbus-Konstruktion.
Der gesamte NUMA (Non-Uniform Memory Access) definiert, wie jede logische CPU auf jeden Teil des Speichers zugreifen kann. Wenn Sie ein System mit zwei Sockeln haben, hat jede CPU (jeder Sockel) ihren eigenen Speicher, auf den sie direkt zugreifen kann. Sie muss aber auch auf den Speicher im anderen Sockel zugreifen können – und das dauert natürlich mehr CPU-Zyklen als der Zugriff auf den lokalen Speicher. NUMA-Knoten geben an, welcher Teil des Systemspeichers lokal für welche CPU ist. Sie können mehrere Topologieebenen haben, zum Beispiel haben Sie im Fall eines HP Superdome-Systems (das Intel Itanium2-CPUs verwendet) lokalen CPU-Sockelspeicher, dann Speicher auf einem anderen Sockel innerhalb derselben Zelle und dann Speicher in anderen Zellen (die die höchste Latenz haben).
Sie können den NUMA in Ihrem System so konfigurieren, dass er die bestmögliche Leistung für Ihre Arbeitslast bietet. Sie können beispielsweise allen CPUs den Zugriff auf den gesamten Speicher oder nur den Zugriff auf den lokalen Speicher erlauben, wodurch sich die Art und Weise ändert, wie der Linux-Scheduler die Prozesse auf die verfügbaren logischen CPUs verteilt. Wenn Sie viele Prozesse haben, die nicht viel Speicher benötigen, kann es von Vorteil sein, nur den lokalen Speicher zu verwenden. Wenn Sie jedoch große Prozesse haben (Oracle-Datenbank mit ihrem gemeinsam genutzten Speicher), ist es möglicherweise besser, den gesamten Speicher aller CPUs zu verwenden.
Sie können Befehle wie numastatoder verwenden numactl --hardware, um den NUMA-Status Ihres Systems 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 die in jedem NUMA-Knoten (CPU-Sockel) vorhandene Speichermenge sehen und wie viel davon verwendet und frei ist.
Der letzte Abschnitt zeigt die NUMA-Topologie – er zeigt die „Entfernungen“ zwischen einzelnen Knoten in Bezug auf die Latenzen beim Speicherzugriff (die Zahlen sind nur relativ, sie stellen keine Zeit in ms oder so dar). Hier können Sie sehen, dass die Latenz zum lokalen Speicher (Knoten 0 greift auf Speicher in 0 zu, Knoten 1 in 1, ...) 10 beträgt, während die Remote-Latenz (Knoten greift auf Speicher auf einem anderen Knoten zu) 21 beträgt. Obwohl dieses System aus 4 einzelnen Blades besteht, ist die Latenz für verschiedene Sockel auf demselben oder einem anderen Blade dieselbe.
Interessantes Dokument über NUMA ist auch unterRedHat-Portal.
Antwort2
Nein. Die Anzahl der NUMA-Knoten entspricht nicht immer der Anzahl der Sockel. Beispielsweise hat ein AMD Threadripper 1950X 1 Sockel und 2 NUMA-Knoten, während ein Dual-System mit Intel Xeon E5310 2 Sockel und 1 NUMA-Knoten aufweisen kann.
Antwort3
Eigentlich nicht. Auf meinem Server:
➜ lscpu
Socket(s): 2
NUMA node(s): 4
NUMA node0 CPU(s): 0-31,128-159
NUMA node1 CPU(s): 32-63,160-191
NUMA node2 CPU(s): 64-95,192-223
NUMA node3 CPU(s): 96-127,224-255
NUMA-Knoten0 und -Knoten1 befinden sich an Sockel 0 und die restlichen beiden an Sockel 1 auf meinem Server.