Всегда ли количество узлов NUMA равно количеству сокетов?

Всегда ли количество узлов NUMA равно количеству сокетов?

Я использовал lscpuдля проверки конфигурации двух серверов:

[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

Другой:

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

Поэтому мне интересно, всегда ли количество узлов NUMA равно количеству сокетов на самом деле. Есть ли пример, где они не равны?

решение1

Почему вас интересует количество узлов NUMA? Важной частью является топология NUMA, которая говорит, как соединены эти «узлы».

Я проверил несколько систем, включая 8-сокетную (10-ядерные ЦП) систему, состоящую из 4 соединенных между собой 2-сокетных лезвий (Hitachi Compute Node 2000). Также здесь количество узлов NUMA равно количеству сокетов ЦП (8). Это зависит от архитектуры ЦП, в основном от конструкции его шины памяти.

Вся NUMA (неоднородный доступ к памяти) определяет, как каждый логический ЦП может получить доступ к каждой части памяти. Когда у вас есть система с 2 сокетами, каждый ЦП (сокет) имеет свою собственную память, к которой он может получить прямой доступ. Но он также должен иметь возможность получить доступ к памяти в другом сокете — и это, конечно, занимает больше циклов ЦП, чем доступ к локальной памяти. Узлы NUMA определяют, какая часть системной памяти является локальной для какого ЦП. У вас может быть больше слоев топологии, например, в случае системы HP Superdome (которая использует ЦП Intel Itanium2), у вас есть локальная память сокета ЦП, затем память на другом сокете внутри той же ячейки, а затем память в других ячейках (которые имеют самую высокую задержку).

Вы можете настроить NUMA в вашей системе так, чтобы она вела себя так, чтобы обеспечить максимально возможную производительность для вашей рабочей нагрузки. Например, вы можете разрешить всем ЦП доступ ко всей памяти или только к локальной памяти, что затем изменит то, как планировщик Linux будет распределять процессы между доступными логическими ЦП. Если у вас много процессов, требующих немного памяти, использование только локальной памяти может быть выгодным, но если у вас большие процессы (база данных Oracle с ее общей памятью), использование всей памяти среди всех ЦП может быть лучшим вариантом.

Вы можете использовать такие команды, как numastatили numactl --hardwareдля проверки статуса NUMA в вашей системе. Вот информация с этой 8-сокетной машины:

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

Там вы можете увидеть объем памяти, присутствующей в каждом узле NUMA (сокете ЦП), а также ее объем, используемый и свободный.

В последнем разделе показана топология NUMA — она показывает «расстояния» между отдельными узлами с точки зрения задержек доступа к памяти (числа являются относительными, они не представляют время в мс или что-либо еще). Здесь вы можете видеть, что задержка локальной памяти (узел 0 обращается к памяти в 0, узел 1 в 1, ...) составляет 10, а удаленная задержка (узел обращается к памяти на другом узле) составляет 21. Хотя эта система состоит из 4 отдельных лезвий, задержка одинакова для разных сокетов на том же лезвии или другом лезвии.

Интересный документ о NUMA также находится по адресуRedHat портал.

решение2

Нет. Количество узлов NUMA не всегда равно количеству сокетов. Например, AMD Threadripper 1950X имеет 1 сокет и 2 узла NUMA, в то время как система с двумя процессорами Intel Xeon E5310 может показывать 2 сокета и 1 узел NUMA.

решение3

На самом деле нет. На моем сервере:

➜ 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 и node1 расположены в сокете 0, а оставшиеся два — в сокете 1 на моем сервере.

Связанный контент