Когда слышал про NUMA, но не понял как все это работает.

Встретил вот такую интересную статью, в которой предлагают бороться с NUMA через CPU Affinity

Краткий комментарий от меня:

1. Задача поддерживать NUMA locality - задача гипервизора
2. Чем больше инфраструктура - тем меньше в нее надо лезть руками
3. При задании CPU affinity слетает миграция и балансировка
4. CPU affinity не имеет смысла, если гипервизор память выделил НЕ на на том же узле

Ну и отдельные перлышки.

В рабочих окружениях мы обычно имеем дело с серверами на 32 и больше ядер.

NUMA массово в x86 появилась во времена Xeon 55xx Nehalem, 2008 год. От 2 до 8 ядер на процессор.

А для работы с большими объёмами оперативки - Non-Uniform Memory Access (NUMA).

Для сокращения пути ядро<->память, а не для большого объема. Объем-то как раз не проблема нарастить, только все упрется в пропускную способность и задержки.

Но виртуальные машины не имеют информации о том, как устроены NUMA-узлы и ядра на хосте

Поэтому размещением машин и локальностью NUMA занимается гипервизор. В этом весь смысл виртуализации.

Но в реальном продакшене

В реальном продакшене количество узлов в кластере может составлять десятки хостов. ВМ постоянно создаются, включаются, выключаются, перемещаются (живая миграции). Как результат идет фрагментация памяти. А управлять процессор должен планировщик процессора и менеджер памяти гипервизора.
Использования CPU affinity для борьбы с NUMA - уровень "чтобы быстрее ползать надо отрубить ноги".