NUMA — архитектура многопроцессорных серверов, при которой память физически разделена между процессорными узлами (NUMA-nodes). Каждый процессор имеет прямой доступ к своей локальной памяти (~70–80 нс latency) и может обращаться к памяти другого процессора через шину QPI/Infinity Fabric (~130–200 нс). Разница в задержках — источник нестабильности производительности при неправильной настройке.
Как работает
На типичном двухпроцессорном сервере с Intel Xeon (например, 2× Xeon Gold 6330, 28 ядер/280 ГБ RAM каждый) — 2 NUMA-узла по 280 ГБ. Если процесс запущен на CPU 0, но занимает память из NUMA-node 1 — каждый доступ к памяти проходит через QPI с дополнительной latency 60–80 нс. При высокой нагрузке это деградирует производительность на 20–40%.
В Linux узнать топологию: numactl --hardware, lstopo (пакет hwloc). Привязать процесс к NUMA-узлу: numactl --cpunodebind=0 --membind=0 ./app. Проверить баланс использования памяти: numastat.
В виртуализации: KVM поддерживает NUMA-топологию ВМ. ВМ можно привязать к физическому NUMA-узлу командой numatune в libvirt. Это критично для больших ВМ (>128 ГБ RAM) и баз данных — PostgreSQL, MySQL.
История
NUMA-архитектура появилась в суперкомпьютерах SGI в 1990-х. В 2000-х Intel внедрил QPI (QuickPath Interconnect) с Nehalem (2008), AMD использует HyperTransport с 2003 года. AMD Infinity Fabric (EPYC Rome, 2019) — современная реализация NUMA с 4–8 узлами на один CPU.
На что обращать внимание
AMD EPYC с архитектурой chiplet имеет внутренние NUMA-узлы даже в пределах одного процессора: EPYC 9654 (96 ядер) состоит из 12 CCD-кристаллов, и неправильное распределение памяти может снизить производительность баз данных. Включайте NUMA_INTERLEAVE=all в PostgreSQL-сервисах для равномерного использования узлов.
Влияние NUMA на производительность
При обращении к памяти удалённого NUMA-узла производительность падает на 20–40%. Latency локального узла — 60–80 нс, удалённого — 100–160 нс на платформах Intel Xeon. PostgreSQL и MySQL особенно чувствительны к NUMA-mismatching.
Управление NUMA в Linux
numactl --hardware — топология узлов. numastat -p PID — статистика hit/miss. Привязка: numactl --cpubind=0 --membind=0 ./app. Для PostgreSQL рекомендуется отключить NUMA-балансирование (kernel.numa_balancing=0).
NUMA в виртуализации
При создании виртуальной машины с большим RAM учитывайте NUMA-топологию хоста. В Proxmox VE включение опции NUMA создаёт виртуальные узлы, отражающие топологию хоста. CPU pinning дополнительно снижает NUMA-накладные расходы.
Диагностика NUMA-проблем
numastat -p $(pgrep mysqld) — показывает numa_miss для MySQL. Если numa_miss > 10% — NUMA mismatching. Решение: numactl --interleave=all mysqld — равномерное распределение по узлам. Для PostgreSQL: запуск через systemd с ExecStart=numactl --interleave=all postgres.
NUMA в PostgreSQL
PostgreSQL рекомендация: vm.numa_balancing=0 и kernel.numa_balancing=0 в /etc/sysctl.conf. В production: запускать PostgreSQL через numactl --interleave=all postgres если numa_miss > 5%. Pgbouncer: разместить на том же NUMA-узле, что и PostgreSQL-процесс.