Le nombre de nœuds NUMA est-il toujours égal à celui des sockets?
J'ai utilisé lscpu pour vérifier la configuration de deux serveurs:
[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
L'autre:
[root@localhost Packages]# lscpu
Architecture: x86_64
.....
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 45
Je me demande donc si le nombre de nœuds NUMA est toujours égal au nombre de sockets. Y a-t-il un exemple où ils ne sont pas égaux?
Pourquoi vous interrogez-vous sur le nombre de nœuds NUMA? La partie importante est la topologie NUMA, qui explique comment ces "nœuds" sont connectés.
J'ai vérifié quelques systèmes, notamment un système à 8 sockets (processeurs à 10 cœurs) constitué de 4 serveurs lames interconnectés à 2 sockets (Hitachi Compute Node 2000). Ici aussi, le nombre de nœuds NUMA est égal au nombre de sockets CPU (8). Cela dépend de l'architecture de la CPU, principalement de la conception de son bus mémoire.
L’ensemble des NUMA (accès non uniformes à la mémoire) définit comment chaque processeur logique peut accéder à chaque partie de la mémoire. Lorsque vous avez 2 systèmes de socket, chaque CPU (socket) possède sa propre mémoire, à laquelle elle peut accéder directement. Mais il doit également pouvoir accéder à la mémoire de l’autre socket, ce qui nécessite bien entendu plus de cycles de la CPU que l’accès à la mémoire locale. Les nœuds NUMA spécifient quelle partie de la mémoire système est locale à quelle CPU. Vous pouvez avoir plusieurs couches de topologie, par exemple dans le cas du système HP Superdome (qui utilise des processeurs Intel Itanium2), vous disposez d'une mémoire de socket de processeur local, puis d'une mémoire sur un socket différent dans la même cellule, puis de la mémoire dans d'autres cellules (qui ont la même capacité). latence la plus élevée).
Vous pouvez configurer le NUMA de votre système pour qu'il se comporte de manière à optimiser les performances de votre charge de travail. Vous pouvez par exemple autoriser tous les processeurs à accéder à toute la mémoire ou uniquement à la mémoire locale, ce qui modifie ensuite la manière dont le planificateur de Linux distribuera les processus entre les processeurs logiques disponibles. Si vous avez beaucoup de processus nécessitant peu de mémoire, utiliser uniquement la mémoire locale peut présenter des avantages, mais si vous avez des processus volumineux (base de données Oracle avec sa mémoire partagée), utiliser toute la mémoire de tous les processeurs peut être préférable.
Vous pouvez utiliser des commandes telles que numastat ou numactl --hardware pour vérifier l'état NUMA sur votre système. Voici les informations de cette machine à 8 prises:
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
Vous pouvez y voir la quantité de mémoire présente dans chaque nœud NUMA (socket CPU) et la quantité de mémoire utilisée et libre.
La dernière section présente la topologie NUMA - elle indique les "distances" entre les nœuds individuels en termes de latence d'accès à la mémoire (les nombres sont uniquement relatifs, ils ne représentent pas le temps en ms ou quoi que ce soit). Vous pouvez voir ici que le temps de latence vers la mémoire locale (le nœud 0 accédant à la mémoire dans 0, le nœud 1 en 1, ...) est égal à 10, tandis que le délai de latence distant (le nœud accédant à la mémoire sur un autre nœud) est égal à 21. Ce système est composé de 4 lames, la latence est la même pour différents sockets sur la même lame ou sur une autre lame.
Un document intéressant sur NUMA se trouve également sur le portail RedHat .
Le nombre de nœuds NUMA n'est pas toujours égal au nombre de sockets. Par exemple, un Threadripper 1950X AMD possède 1 socket et 2 nœuds NUMA, alors qu'un système dual Intel Xeon E5310 peut afficher 2 sockets et 1 nœud NUMA.