На многосокетном сервере общий объём свободной RAM не описывает качество памяти для СУБД. Процесс выполняется на конкретных ядрах, а данные находятся в банках DRAM, связанных с определёнными процессорными сокетами. Если путь к странице проходит через межсокетное соединение, профиль задержки и пропускной способности меняется.

NUMA — неоднородный доступ к памяти — заставляет смотреть на сервер как на топологию, а не как на единую коробку с гигабайтами. Локальная память расположена ближе к выполняющему поток процессору. Удалённая остаётся полноценной DRAM, но доступ к ней проходит другой маршрут и конкурирует за другие ресурсы платформы.

Поэтому правильная архитектурная последовательность начинается с локальности, продолжается проверкой p99 и SLO и только затем переходит к расширению ёмкости. Дополнительная память полезна, когда понятно, какие процессоры и страницы образуют критичный путь. Иначе новая RAM способна увеличить общий запас, не устранив источник нестабильной задержки.

NUMA превращает память в топологию

В NUMA-системе каждый узел объединяет процессорные ядра и близкую им память. Другие узлы доступны, поэтому приложение видит единое адресное пространство, но физический маршрут обращения различается. Именно это означает слово «неоднородный»: одинаковый адресный интерфейс не гарантирует одинаковую стоимость каждого доступа.

Linux описывает memory policy как правило, определяющее, с каких NUMA-узлов ядро выделяет физические страницы. Политика может действовать для процесса или отдельной области его адресного пространства. На размещение также влияют разрешённые наборы процессоров и узлов, поэтому CPU и память рассматриваются совместно.

Страница часто получает физическое место при первом фактическом обращении. Если поток и политика памяти не согласованы, значительная часть рабочего набора может оказаться на узле, отличном от того, где затем выполняется работа. Свободная память на соседнем сокете помогает вместить данные, но не становится автоматически равноценной локальному пути.

Официальное руководство AMD для СУБД описывает выбор NUMA-конфигурации как баланс локальной задержки и доступной пропускной способности. Материал Intel показывает дополнительный межсокетный маршрут к удалённой памяти на рассматриваемой платформе. Универсального процента разницы здесь нет: результат зависит от поколения процессора, топологии и профиля обращений.

Локальность защищает хвост задержки

Средняя задержка может скрыть редкие, но дорогие обращения. Для СУБД они проявляются в p99 — границе, быстрее которой завершается 99% операций. Если критичный запрос иногда проходит через удалённую память одновременно с фоновой работой, среднее значение выглядит приемлемо, а хвост распределения растёт.

Для бизнеса важен не сам факт удалённого доступа, а его связь с SLO. Соглашение об уровне обслуживания задаёт допустимую задержку и доступность сервиса. Архитектор сопоставляет p99 бизнес-операций с размещением потоков, страниц и периодами конкуренции за межсокетный путь.

Linux поддерживает automatic NUMA balancing. Ядро выборочно наблюдает, какие потоки обращаются к страницам, и может перемещать память ближе к часто использующему её узлу. Это системный контур адаптации локальности. Он показывает, что расположение страниц — динамическая характеристика работающей нагрузки, а не только параметр спецификации сервера.

Ёмкость добавляется после фиксации локальности

Когда путь к DRAM понятен, возникает второй вопрос: какой объём быстрого уровня действительно нужен рабочему набору и как обслужить рост данных без линейного увеличения физической памяти. Это уже не задача NUMA. NUMA выбирает близость внутри DRAM, а многоуровневая память определяет, какой физический уровень обслуживает страницу в данный момент.

В этой роли gigaRAM использует предиктивную математическую модель: по реальным обращениям она решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Управление выполняется ниже приложения, без ручной разметки страниц. NUMA-locality и физическая ёмкость связаны общим путём запроса, но остаются разными контурами.

Рабочий набор СУБД меняется вместе с транзакциями, отчётами и фоновыми операциями. Поэтому измерение границы рабочего набора через refault, p99 и давление памяти дополняет NUMA-картину: локальность отвечает на вопрос «где находится быстрая страница», а рабочий набор — «какой объём сейчас требует быстрого уровня».

NVMe не превращает удалённую DRAM в локальную и не управляет привязкой потоков. Его роль — добавить управляемую физическую ёмкость после того, как платформа зафиксировала размещение CPU и DRAM. Такая последовательность сохраняет причинность: сначала устраняется неопределённость пути, затем сравниваются варианты расширения памяти.

Дерево решения сохраняет правильный порядок

Архитектурное решение можно свести к четырём ветвям. Они не заменяют измерения и не задают универсальную конфигурацию, а помогают командам обсуждать один и тот же критичный путь.

  • Если p99 растёт вместе с долей удалённых обращений → проверить размещение потоков и страниц → сначала согласовать NUMA-политику и SLO.
  • Если локальность стабильна, но рабочий набор регулярно упирается в DRAM → проверить refault и давление памяти в критичный период → рассматривать дополнительную управляемую ёмкость.
  • Если общий запас RAM велик, а один узел перегружен → проверить распределение памяти по сокетам → исправить топологический перекос до новой закупки.
  • Если p99 стабилен, а рост данных требует новых узлов → сравнить плотность и стоимость обслуженной нагрузки → выбрать масштабирование DRAM, DRAM+NVMe или числа серверов.

Дерево отделяет причину от ресурса. Удалённый путь требует решения локальности, нехватка быстрого объёма — решения ёмкости, а рост полезной нагрузки — экономического сравнения конфигураций. Покупка RAM остаётся одним из вариантов, но перестаёт маскировать топологический сигнал.

Решением владеют три команды

Платформенная команда отвечает за серверную топологию, размещение CPU и памяти, NVMe и наблюдаемость узла. DBA знает профиль СУБД, фоновые операции, критичные запросы и поведение буферов. Владелец сервиса определяет SLO и цену задержки для бизнеса. Решение о памяти принадлежит им совместно.

Такое распределение ответственности особенно важно при консолидации. Повышение плотности виртуальных машин при неодновременных пиках памяти может улучшить использование сервера, но NUMA-топология остаётся частью критичного пути. Количество экземпляров оценивают вместе с локальностью и p99, а не только по сумме выделенной RAM.

Сигнал для инвестиций возникает, когда локальность уже контролируется, а рост рабочего набора продолжает требовать новых модулей или узлов. Тогда платформа может сравнить стоимость конфигураций, DBA — подтвердить профиль нагрузки, а владелец сервиса — проверить число операций в пределах SLO. Ёмкость становится осознанной инвестицией, а не реакцией на единственный график свободной памяти.

Для CTO итоговая мера — стоимость обслуженной нагрузки при целевом p99. В неё входят DRAM, NVMe, число серверов, эксплуатация и цена нарушения SLO. Плотность имеет смысл лишь тогда, когда дополнительный экземпляр СУБД не разрушает предсказуемость доступа к памяти в совместный пик.

Локальность и ёмкость образуют две оси роста

NUMA отвечает на вопрос о близости процессора и DRAM. Предиктивная память отвечает на вопрос о том, какой объём должен находиться на быстром уровне сейчас и какой может обслуживаться управляемым уровнем ёмкости. Объединение этих осей даёт архитектуре ясный порядок принятия решений.

В такой модели gigaRAM дополняет, а не подменяет NUMA-дисциплину. Инфраструктурный слой управляет ёмкостью DRAM+NVMe, тогда как операционная система и платформа сохраняют ответственность за топологию. Это позволяет увеличивать доступный объём и плотность СУБД без ручной карты страниц и без смешения двух разных причин задержки.

Для бизнеса последовательность проста: локальность защищает предсказуемость, SLO фиксирует требуемый результат, а ёмкость масштабирует обслуживаемый объём. Именно в этом порядке память перестаёт быть набором разрозненных гигабайт и становится управляемой архитектурой сервера.

Источники. Документация Linux о NUMA memory policy описывает выбор узлов для выделения памяти и область действия политик. Документация Linux об automatic NUMA balancing объясняет наблюдение за обращениями и автоматическое перемещение памяти.

AMD EPYC 9004 RDBMS Tuning Guide используется как первичный источник о балансе локальной задержки и пропускной способности в NUMA-конфигурации СУБД. Intel DPDK Performance Optimization Guidelines подтверждает влияние межсокетного маршрута к удалённой памяти на рассмотренной платформе.

Технология gigaRAM служит только источником описания предиктивного размещения страниц между DRAM и NVMe. Свойства NUMA-балансировки и результаты производителей процессоров на продукт не переносились.