¿La cantidad de nodos NUMA es siempre igual a la de sockets?

¿La cantidad de nodos NUMA es siempre igual a la de sockets?

He utilizado lscpupara comprobar la configuración de dos servidores:

[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

El otro:

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

Entonces me pregunto si, de hecho, la cantidad de nodos NUMA siempre es igual a sockets. ¿Hay algún ejemplo en el que no sean iguales?

Respuesta1

¿Por qué se pregunta acerca de la cantidad de nodos NUMA? La parte importante es la topología NUMA, que dice cómo están conectados esos "nodos".

He comprobado algunos sistemas, incluido un sistema de 8 zócalos (CPU de 10 núcleos) que consta de 4 blades de 2 zócalos interconectados (Hitachi Compute Node 2000). También aquí la cantidad de nodos NUMA es igual a la cantidad de zócalos de CPU (8). Esto depende de la arquitectura de la CPU, principalmente del diseño del bus de memoria.

El NUMA completo (acceso a memoria no uniforme) define cómo puede cada CPU lógica acceder a cada parte de la memoria. Cuando tienes un sistema de 2 sockets, cada CPU (socket) tiene su propia memoria, a la que puede acceder directamente. Pero también debe poder acceder a la memoria en el otro socket, y esto, por supuesto, requiere más ciclos de CPU que acceder a la memoria local. Los nodos NUMA especifican qué parte de la memoria del sistema es local para cada CPU. Puede tener más capas de topología, por ejemplo, en el caso del sistema HP Superdome (que usa CPU Intel Itanium2), tiene memoria de socket de CPU local, luego memoria en diferentes sockets dentro de la misma celda y luego memoria en otras celdas (que tienen la latencia más alta).

Puede configurar el NUMA en su sistema para que se comporte de manera que brinde el mejor rendimiento posible para su carga de trabajo. Por ejemplo, puede permitir que todas las CPU accedan a toda la memoria, o que solo accedan a la memoria local, lo que luego cambia la forma en que el programador de Linux distribuirá los procesos entre las CPU lógicas disponibles. Si tiene muchos procesos que requieren poca memoria, puede ser beneficioso usar solo la memoria local, pero si tiene procesos grandes (base de datos Oracle con su memoria compartida), podría ser mejor usar toda la memoria entre todas las CPU.

Puede utilizar comandos como numastato numactl --hardwarepara comprobar el estado de NUMA en su sistema. Aquí hay información de esa máquina de 8 enchufes:

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

Allí puede ver la cantidad de memoria presente en cada nodo NUMA (zócalo de CPU) y cuánta está utilizada y libre.

La última sección muestra la topología NUMA: muestra las "distancias" entre nodos individuales en términos de latencias de acceso a la memoria (los números son sólo relativos, no representan el tiempo en ms ni nada por el estilo). Aquí puede ver que la latencia a la memoria local (el nodo 0 accede a la memoria en 0, el nodo 1 en 1, ...) es 10 mientras que la latencia remota (el nodo accede a la memoria en otro nodo) es 21. Aunque este sistema consta de 4 unidades individuales Blades, la latencia es la misma para diferentes enchufes en la misma Blade o en otra Blade.

Un documento interesante sobre NUMA también está enPortal RedHat.

Respuesta2

No. La cantidad de nodos NUMA no siempre es igual a la cantidad de sockets. Por ejemplo, un AMD Threadripper 1950X tiene 1 zócalo y 2 nodos NUMA, mientras que un sistema dual Intel Xeon E5310 puede mostrar 2 zócalos y 1 nodo NUMA.

Respuesta3

En realidad no. En mi servidor:

➜ 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 node0 y node1 se ubican en el socket 0 y los dos restantes se ubican en el socket 1 de mi servidor.

información relacionada