Перейти к содержимому 
Память NUMA определяет, насколько близко к необходимой памяти работают потоки на крупных серверах баз данных и насколько задержки влияют на время отклика и пропускную способность. Я целенаправленно согласовываю распределение ресурсов ЦП, размещение в памяти и размер рабочей нагрузки, сокращаю удаленные обращения и тем самым обеспечиваю надёжную, предсказуемую Производительность.
Центральные пункты
- Топология понимать: целенаправленно учитывать узлы, ядра, оперативную память и межкомпонентные соединения.
- Политика Выберите подходящий режим: Strict, Preferred, Interleave в зависимости от целей рабочей нагрузки.
- аффинность Реализация: локальная привязка потоков, IRQ и памяти.
- Виртуальные машины по размеру узла: разместить vCPU и ОЗУ в одном узле NUMA.
- Мониторинг Провести: измерение удалённых чтений, задержки P99 и нагрузки на узлы.
Понимание топологии NUMA
Я начинаю каждую оптимизацию с Топология: Сколько существует NUMA-узлов, как распределены ядра, как оперативная память подключена к сокелам и насколько затратны операции доступа к межузловой сети. Доступ к локальной памяти занимает значительно меньше времени, чем доступ через границы узлов, поэтому я избегаю ненужных Удаленный-Способы. Крупные серверы баз данных работают эффективнее, если я планирую рабочие нагрузки таким образом, чтобы потоки и данные оставались на одном узле. Если объем активных данных не помещается на одном узле, я сознательно планирую их распределение, а не полагаюсь на стандартное поведение. Таким образом, я поддерживаю Латентность низкий и обеспечивает равномерную пропускную способность даже при высокой нагрузке.
Правильно выбрать настройки BIOS и оборудования
Я проверяю в BIOS, что Чередование узлов отключена, чтобы сохранить NUMA-разделение. Я распределяю каналы памяти симметрично по разъемам и слежу за конфигурацией (1DPC против 2DPC), чтобы не допустить ненужного падения тактовой частоты и пропускной способности. Такие функции, как C-состояния А в агрессивных режимах энергосбережения я настраиваю целевые значения задержки более консервативно, чтобы ядра не приходилось постоянно выходить из режима ожидания. SMT/гиперпотоки Я оцениваю их с учетом конкретных рабочих нагрузок: для OLTP-нагрузок, в значительной степени зависящих от памяти, я ограничиваю количество параллельно активных SMT-потоков на каждое ядро, чтобы снизить нагрузку на кэш и уменьшить изменчивость. Кроме того, я проверяю, чтобы устройства PCIe (сетевые карты, NVMe) подключались локально к каждому разъёму, чтобы их IRQs и чтобы пути DMA не проходили через межкомпонентную связь. Тот, кто тщательно подойдет к этому вопросу, заложит основу, на которой будут эффективно работать политики и аффинности.
Правильный выбор политик управления памятью
Выбор Политика определяет, с какого узла ядро выделяет память и как реализуются резервные варианты. Параметр «Strict» устанавливает жесткие ограничения и прерывает выделение памяти, если на целевом узле нет свободного места; при этом приоритет отдается Производительность о гибкости. Стратегия «Preferred» использует предпочтительный узел, но в случае нехватки ресурсов переключается на другие, предлагая таким образом золотую середину. Interleave распределяет страницы по нескольким узлам по принципу «round-robin», что может быть целесообразно при работе с очень большими массивами данных, которые используются равномерно. Для многих баз данных локальная стратегия с использованием Preferred или Strict, как правило, является более предпочтительной Выбор.
| Политика | Провести | Типичное использование | Преимущества | Риски |
|---|---|---|---|---|
| Строгий | Операция чтения выполняется только из целевого узла, в противном случае возникает ошибка | Скрытокритические Базы данных с четким планом размещения узлов | Максимально локальная Доступы, прогнозируемые задержки | Распределение может завершиться неудачей, если узел переполнен |
| Предпочтительный | Предпочтительный узел, возможен переход на другой | Общие сведения Рабочие нагрузки с переменной нагрузкой | Удобное расположение при приемлемой гибкости | Увеличение доли удаленной работы в условиях дефицита |
| Interleave | Очередность «Round-Robin» с участием нескольких узлов | Очень большие, широко используемые Данные | Распределение нагрузки между несколькими узлами | Менее благоприятное местоположение, потенциально более высокая задержка |
Потоки, аффинность к процессору и привязка к памяти
Я привязываю потоки к ядрам целевого узла, связываю области памяти с помощью numactl и выравниваю IRQ так, чтобы Данные оставаться локальным. Такое сочетание аффинности к ЦП и привязки к памяти сокращает количество ресурсоемких удаленных чтений и сужает распределение времени выполнения. Для более тонкого контроля я использую политики на уровне процессов или потоков и размещаю пул буферов как можно ближе к активным рабочим потокам. Те, кто хочет углубиться в тему, найдут практические инструкции по Сродство к процессору, которые можно напрямую применять на рабочих хостах. Таким образом я обеспечиваю согласованность Задержки даже при высокой загрузке системы.
Уделять приоритетное внимание местным «хотсетам»
Я выделяю «горячие наборы» из Рабочая нагрузка и размещаю их строго локально, в то время как «холодные» данные можно размещать более гибко. Благодаря такой приоритезации я остаюсь близко к оперативной памяти узла на основных путях. При увеличении нагрузки решение масштабируется плавно, поскольку ресурсоемкие пути по-прежнему выполняются локально. Без такого упорядочения кривая задержки начинает скакать, как только потоки все чаще обращаются к данным через несколько узлов. Четкое Переплет надежно предотвращает именно такое поведение.
Объединение NUMA-систем хранения данных и сети
Я организую Сетевые карты и NVMe-Устройства целенаправленно привязываю к сокелам и направляю их IRQ на локальные ядра. Управление приемом/передачей (RSS/RPS/XPS) я поддерживаю единообразно для каждого узла, чтобы пакеты обрабатывались там же, где работают потоки базы данных. При использовании NVMe я применяю несколько очередей на каждое ядро и привязываю потоки ввода-вывода локально, чтобы пути журналов и данных не перемещались через межкомпонентную связь. Для репликации я разделяю сетевые пути по узлам, чтобы входящие потоки WAL/Redo поступали локально. Таким образом, IO– и траектории ЦП совпадают, а база данных не тратит циклы на ненужные копирования по всему массиву памяти.
Планирование виртуальных машин с учетом размера узла
Я подбираю размеры виртуальных машин таким образом, чтобы количество vCPU и объем оперативной памяти помещались в один физический узел NUMA, поскольку это снижает Латентность и межузловой трафик. Виртуальные машины (VM) с широким охватом, размер которых превышает размер одного узла, неизбежно распределяют обращения к памяти, что приводит к потере предсказуемости. Если виртуальная машина должна быть больше, я явно планирую vNUMA и слежу за симметричным распределением по узлам. Что касается хоста, я избегаю переподписки при рабочих нагрузках с высокой задержкой и резервирую локальную память для каждой виртуальной машины. Краткий обзор физической структуры узлов можно найти в „Планирование узлов NUMA“, что упрощает принятие решений относительно размера виртуальной машины и Ошибка при размещении.
Учитывайте настройки гипервизора
Я проверяю, как гипервизор представляет vNUMA, и отслеживаю сопоставление групп vCPU физическим Ядра последовательно. Кроме того, я слежу за тем, чтобы топология NUMA виртуальной машины соответствовала топологии хоста, чтобы планировщик мог работать локально. Резервирование памяти и правила антиаффинности я устанавливаю настолько минимальными, насколько это возможно, но настолько строгими, насколько это необходимо. Высокую плотность виртуальных машин на одном сокеле я предпочитаю заменять распределением вблизи узлов. Таким образом, я Удаленный-Сведите количество обращений к минимуму и обеспечьте стабильность путей ввода-вывода.
Практика работы с контейнерами и оркестровками
В контейнеры я помещаю cpuset-Согласованность границ: процессоры и соответствующие маски памяти (cpuset.cpus, cpuset.mems) взаимосвязаны. Systemd-Slices и Units получают фиксированные аффиниты процессора, чтобы ядро действительно обеспечивало приоритетную обработку памяти. На уровнях оркестрации я планирую использовать поды/сервисы рядом с узлом, использую оценку топологии и статическое распределение ресурсов ЦП, чтобы рабочая нагрузка не переключалась между узлами. Huge Pages я явно объявляю для каждого под/контейнера и поддерживаю их размер и количество на каждом узле на постоянном уровне. Важно: инфраструктурные и вспомогательные процессы (ведение журналов, сайдкары, резервное копирование) я привязываю к другим ядрам или даже к другому NUMA-узлу, чтобы не мешать «горячим наборам» базы данных.
Балансировка NUMA и настройка операционной системы
Автоматическая балансировка NUMA может локализовать Доступы улучшить, когда рабочие нагрузки перемещаются или фазы значительно меняются. Я использую эту функцию целенаправленно, но при этом слежу за тем, не приносит ли перемещение страниц туда-сюда больше вреда, чем пользы. Жестко заданные процессы с чёткой аффинностью часто выигрывают от ручной настройки политик, а не от постоянного перераспределения ресурсов. Параметры ядра, управление IRQ и прозрачные Huge Pages я проверяю в контексте конкретной базы данных и платформы. В качестве отправной точки мне помогает следующее: Балансировка NUMA-Руководство по пошаговому тестированию настроек и рассеяние сократить задержки.
Целенаправленное использование Huge Pages
Я использую Huge Pages для сокращения количества промахов TLB и обработки больших Памятьболее эффективно обрабатывать области. Для серверов баз данных я заранее резервирую страницы, распределяю их по узлам и проверяю, действительно ли экземпляр их использует. Я часто отключаю Transparent Huge Pages при определенных целевых показателях задержки и устанавливаю статические Huge Pages, чтобы аллокация оставалась детерминированной. Однако решающим фактором по-прежнему остается близость к узлу NUMA; Huge Pages усиливают эффективную стратегию, но не заменяют её. Тот, кто игнорирует это, вряд ли выиграет Производительность и рискует столкнуться с побочными эффектами при страничной организации памяти.
Расчет размеров баз данных: буферный пул и объем работы
Я планирую объем активной работы таким образом, чтобы буферный пул, кэши блокировок и планов, а также наиболее часто используемые таблицы вместиться в один узел. В случае очень крупных экземпляров я разделяю сервисы или шарды по узлам, вместо того чтобы распределять один огромный монолитный экземпляр по всем узлам. Для задач OLTP я поддерживаю буферный пул на каждом узле компактным и отдаю приоритет локальным показателям попадания. Для сканирования OLAP в особых случаях может быть целесообразно использовать чередование (interleave), если объем данных гигантский и равномерно распределен. Без соблюдения этой дисциплины растёт Соединение-потребляет энергию и расходует резервы именно в моменты пиковых нагрузок.
Хитрости, характерные для конкретных баз данных
Я учитываю модель процессов и потоков движка: PostgreSQL использует процессы, поэтому я запускаю основной экземпляр, Autovacuum и Checkpointer отдельно для каждого узла и поддерживаю shared_buffers локально для каждого шарда. При MySQL/InnoDB я сортирую экземпляры буферного пула на узле и настраивай локальную ориентацию потоков ввода-вывода и модулей записи в журнал. SQL Server использует преимущества адаптированной архитектуры Soft-NUMA и схемы распределения, при которой планировщики и группы памяти группируются по физическим узлам. Oracle-Я развертываю инстансы с использованием локальных больших страниц и распределяю рабочие серверы и серверы ввода-вывода по узлам. В целом я снижаю конкуренцию за арены в аллокаторе (например, jemalloc) за счет использования арен, оптимизированных для NUMA, и слежу за тем, чтобы Менеджер блокировок и обеспечить локализацию «горячих точек» блокировки, распределяя разбиение на разделы и шардирование по узлам.
Мониторинг: показатели, которые имеют значение
Я измеряю количество удаленных чтений, трафик межузлового соединения, количество сбоев страниц на узел и показатель P99-Латентность соответствующих запросов. Кроме того, я отслеживаю загрузку ЦП по каждому узлу, коэффициенты NUMA-Miss и долю обращений к локальной памяти. Этот обзор показывает, действует ли политика или потоки бесконтрольно обращаются к удаленным страницам. Я сопоставляю пиковые значения с решениями планировщика, событиями миграции и ошибками выделения памяти. Только эти метрики подтверждают, что Политика не только в лабораторных условиях, но и на постоянной основе в производственной системе.
Стратегия тестирования и внедрение
Я провожу тестирование поэтапно: сначала микробенчмарки для Полоса пропускания и задержку на узел, а затем — реалистичные рабочие нагрузки с «холодным» и «теплым» кэшем. Нагрузку повышаю постепенно, измеряю показатели P95/P99/P99,9 и отслеживаю распределение, а не только средние значения. Я документирую каждое изменение (политики, аффинности, Huge Pages, перенаправление IRQ) и провожу A/B-тестирование в идентичных условиях. Перед развертыванием я определяю Критерии отмены и план отката, чтобы в случае регрессий я мог быстро вернуться к предыдущей конфигурации. Краткий тест на устойчивость под постоянной нагрузкой позволяет выявить Дрейф и миграции, которые на коротких отрезках остаются незаметными.
Пошаговая инструкция
Сначала я ввожу Топология: количество узлов, распределение ядер, каналы памяти и межкомпонентная связь. Затем я определяю целевую рабочую нагрузку на каждый узел и проверяю, поместятся ли в неё «горячие наборы». На следующем этапе я настраиваю аффинность ЦП, маршрутизацию IRQ и привязку памяти на уровне процессов или потоков. Затем я включаю или отключаю NUMA-балансировку в зависимости от динамики рабочей нагрузки и, при необходимости, резервирую огромные страницы (Huge Pages) для каждого узла. В заключение я проверяю результат с помощью повторяемых нагрузочных тестов и отслеживаю Основные показатели при непрерывной работе.
Практические примеры и трудности
OLTP-инстанс с большим количеством коротких транзакций демонстрирует заметный прирост производительности, если настроить рабочие потоки и буферный пул на Узел задайте и установите параметр „Strict“ или «Preferred». Хранилище данных с широким охватом сканирования может извлечь выгоду из режима «Interleave», если данные используются очень равномерно, а загрузка узлов оптимальна. Виртуальные машины заметно теряют предсказуемость, как только они выходят за пределы узлов, и гипервизор начинает распределять память с смещением. Я часто наблюдаю, что одна «широкая» виртуальная машина перегружает межузловую связь и тем самым замедляет работу соседних виртуальных машин. Эти эффекты исчезают, как только я перехожу к локальному Распределение и вернуться к чистой конфигурации vNUMA.
Сценарии ошибок и антипаттерны
С Строгий я повышаю риск сбоев при выделении памяти и срабатывания OOM-киллера. Поэтому я оставляю свободные резервы на целевом узле, отслеживаю неудачные попытки и определяю резервные варианты (например, целенаправленное изменение размера вне часов пиковой нагрузки). Transparent Huge Pages в всегда-режим вызывает в путях задержки Дефрагментация и конюшен — я использую статические бронирования или включаю THP madvise. Автоматическая балансировка NUMA может перемещать страницы туда и обратно при колебаниях нагрузки; если я замечаю признаки «отскока» страниц, я снова вручную настраиваю политики. В виртуальных машинах Воздушные шары а сжатие памяти — настоящий яд для предсказуемости; для критически важных баз данных я отключаю эти функции. Миграцию между узлами в режиме реального времени я планирую только в окнах простоя или сначала перемещаю данные на стороне базы данных, чтобы межузловая связь не перегрузилась вторично.
Планирование производственных мощностей и рост
Я планирую по одному Резерв Я настраиваю 10–20 % для пиковых нагрузок, Autovacuum/Compaction и периодических заданий обслуживания. При увеличении объема данных я сначала масштабирую систему по узлам (шардам/сервисам), а не слепо увеличиваю весь буферный пул. Я предотвращаю незаметный „скрытый рост“ с помощью жестких ограничений на каждый узел и оповещений, как только локальные показатели попадания снижаются или доля удаленных операций увеличивается. При составлении прогнозов на следующие кварталы я учитываю не только объемы данных, но и Показатели транзакций а также изменения в распределении доступа, поскольку они зачастую приводят к перемещению «горячих наборов» быстрее, чем это обусловлено исключительно потребностями в памяти. Таким образом, платформа остается стабильной, а расширение происходит контролируемым образом, без ущерба для локальности NUMA.
Короткий баланс
Я оптимизирую крупные серверы баз данных следующим образом: NUMA-Чётко согласовывать топологию, политики и размер рабочей нагрузки. Локальное распределение памяти позволяет сэкономить решающие миллисекунды, в то время как незапланированные удалённые обращения увеличивают задержку P99. В будущем я планирую развертывать виртуальные машины таким образом, чтобы они помещались в узлы или четко использовали vNUMA. Я целенаправленно использую настройки операционной системы, аффинности и Huge Pages, проверяю их эффект и внедряю изменения только на основе результатов измерений. Тот, кто примет во внимание эти шаги, достигнет ожидаемой Производительность состоит из современного оборудования и обеспечивает стабильную и высокую производительность платформ даже при высокой нагрузке.
