Перейти к содержимому 
Die архитектура NUMA определяет, насколько быстро современные серверы снабжают потоки памятью и насколько хорошо рабочие нагрузки масштабируются при высокой нагрузке. Я покажу, почему локальный доступ к памяти доминирует над задержкой и пропускной способностью, как гипервизоры используют NUMA и какие настройки в виртуальных машинах обеспечивают непосредственное повышение производительности.
Центральные пункты
Я кратко обобщу основные выводы и выделю факторы, которые оказывают наибольшее влияние на работу центров обработки данных.
- Локальная память минимизирует задержку и повышает пропускную способность
- NUMA-узел эффективно структурируют ЦП и ОЗУ
- Размер vCPU подстроить под размер узла для каждой виртуальной машины
- Виртуальная NUMA передавать в гостевую ОС
- Правила натяжения для больших потребностей в оперативной памяти
Я последовательно сосредотачиваюсь на Латентность и близость данных, потому что именно там определяется производительность сервера. Большие сокеты, много ядер и много оперативной памяти мало что дают, если потоки постоянно ждут удаленные области памяти. Я масштабирую виртуальные машины так, чтобы они помещались в один узел NUMA, а распределение памяти оставалось локальным. Я поддерживаю функции гипервизора выборочно, а не активирую все глобально. Таким образом я обеспечиваю Масштабирование без неожиданностей при пиковых нагрузках.
Что действительно отличает NUMA
Я думаю в Узел: Каждый узел NUMA объединяет ядра ЦП и локальную область ОЗУ с очень короткими путями доступа. Если поток находит данные в кэше L1, L2 или L3, все работает очень быстро; если набор данных находится в локальной ОЗУ, задержка остается низкой. Однако, если поток обращается к другому узлу, время ожидания увеличивается, а пропускная способность падает. Именно эти различия делают Неуниформа Доступ к памяти. Поэтому я организую рабочие нагрузки таким образом, чтобы большая часть доступа оставалась локальной.
Почему UMA сталкивается с ограничениями
UMA предоставляет всем процессорам общий путь хранения что при увеличении количества ядер приводит к заторам. Каждое дополнительное ядро попадает в те же очереди и конкурирует за пропускную способность. Во многих старых конфигурациях это приводило к накоплению задержек, в результате чего загрузка ЦП была высокой, но приложение реагировало медленно. Это ощущается как „ЦП на пределе“, хотя на самом деле узким местом является доступ к памяти. NUMA решает именно эту проблему. Засоры посредством локальных путей и топологии узлов.
NUMA и UMA: обзор различий
Я хотел бы кратко изложить основные различия в компактной форме. Таблица , чтобы решения принимались быстрее. Этот обзор показывает, что важно в архитектуре, задержке и масштабировании. Он помогает мне в определении размера новых хостов, а также в поиске ошибок в производственных средах. Тот, кто четко видит разницу между локальным и удаленным доступом, принимает более правильные решения при настройке виртуальных машин и распределении оперативной памяти. Именно здесь решается Производительность под нагрузкой.
| Критерий | NUMA | UMA | Практический эффект |
|---|---|---|---|
| доступ к памяти | Локально или удаленно | Стандартизированный | Локальный доступ быстрее; удаленный доступ имеет задержку |
| Масштабирование | Очень хорошо с узлами | Раннее ограничение | Большее количество ядер обеспечивает более надежную масштабируемость в NUMA |
| Топология | Несколько узлов | Единый пул | Необходимость планирования с учетом топологии |
| гипервизор | Виртуальная NUMA доступна | Менее актуально | Гостевая ОС может планировать с учетом NUMA |
| точная настройка | vCPU/RAM на узел | Глобальный тюнинг | Виртуальные машины, соответствующие узлам, обеспечивают стабильность |
NUMA в виртуальных средах
Я позволяю гипервизору Топология передавать гостевой ОС, чтобы планировщик и управление памятью выполнялись локально. Virtual NUMA показывает гостю границы его узлов, благодаря чему базы данных, JVM и .NET-рабочие процессы более эффективно организуют свои кучи и потоки. Таким образом я избегаю дорогостоящего удаленного доступа и поддерживаю стабильную задержку. В чувствительных настройках я комбинирую это с последовательной стратегией привязки и фиксированным распределением RAM. Для чрезвычайно короткого времени отклика я дополнительно использую Хостинг с микрозадержкой , чтобы еще больше снизить джиттер.
Лучшие практики для размеров виртуальных машин и распределения ресурсов ЦП
Я определяю размеры виртуальные процессоры так, чтобы виртуальная машина помещалась в узел NUMA или лишь слегка затрагивала его. Пример: если хост имеет два узла по 20 ядер, я предпочитаю планировать виртуальные машины с 4–16 виртуальными процессорами внутри одного узла. Если превысить это количество, возникает риск удаленного доступа и ненужных задержек. Я распределяю RAM по возможности статически, чтобы гостевая ОС хранила свои страницы локально. Для рабочих нагрузок с большой долей однопоточных процессов я использую правильную стратегию ядер и аналитику, такую как Однопоточный и многоядерный.
Конкретные преимущества для хостинг-оборудования
С помощью тщательного планирования NUMA я повышаю плотность на хост, без ущерба для времени отклика. Во многих центрах обработки данных это позволяет запускать значительно больше виртуальных машин на каждом сокеле, при этом приложения продолжают надежно реагировать. Меньшая задержка напрямую влияет на пользовательский опыт и пропускную способность пакетной обработки. Стоимость нагрузки снижается, поскольку время процессора и оперативная память используются более эффективно. Те, кто делает осознанный выбор оборудования, дополнительно выигрывают от современных Высокопроизводительное оборудование для веб-хостинга с высокой пропускной способностью памяти.
Настройка рабочей нагрузки: базы данных, кэши, контейнеры
Я слежу за тем, чтобы Базы данных хранить свои кучи локально и выполнять рабочие потоки на „своем“ узле. Для SQL-движков, кэшей в памяти и JVM целесообразно использовать фиксированное распределение ЦП и резервирование памяти. Оркестрация контейнеров выигрывает от аффинности узлов, так как поды используют самые короткие пути хранения. При интенсивном вводе-выводе я использую распределение NVMe, близкое к NUMA, чтобы данные оставались вблизи узлов. Таким образом, горячие пути остаются короткими, а Время отклика дружелюбный.
Мониторинг и устранение неполадок в NUMA
Я измеряю Латентность и удаленный доступ, а не просто смотреть на проценты загрузки ЦП. Инструменты показывают мне, сколько страниц находится удаленно на каждом узле и какие потоки создают нагрузку на память. Если удаленные промахи увеличиваются, я корректирую размер vCPU, аффинности или распределение ОЗУ. Если пропускная способность остается низкой, несмотря на высокие резервы ЦП, часто причиной являются пути доступа к памяти. Видимость на уровне узла — для меня это самый быстрый способ Причины, а не только к симптомам.
NUMA-Spanning: правильное использование
Я активирую Напряжение специально для виртуальных машин с очень большими потребностями в оперативной памяти или необычной пропускной способностью. Виртуальная машина может затем получать память через несколько узлов, что делает возможным использование отдельных экземпляров с огромным объемом памяти. Цена за это — случайные удаленные обращения, которые я смягчаю с помощью аффинности к ЦП и большей доли локальности страниц. При смешанных нагрузках я предпочитаю выбирать несколько виртуальных машин среднего размера вместо одного очень большого экземпляра. Таким образом, остается Планируемость в повседневной жизни.
Лицензирование, плотность и реальные затраты
I ставка Стоимость не на уровне хоста, а за рабочую нагрузку и месяц в евро. Когда NUMA увеличивает плотность виртуальных машин, фиксированные затраты на каждый экземпляр снижаются, а резервы производительности растут. Это влияет на лицензии на каждое ядро, а также на затраты на поддержку и энергию. Сокращение удаленного доступа сокращает время вычислений и экономит энергию при выполнении той же задачи. В конце концов, важна Общий баланс из евро за результат, а не просто евро за сервер.
Правильное чтение топологии оборудования и межсоединений
Я отношусь к физическому Топология активно учитываю в своем планировании. Современные серверы используют многокомпонентные конструкции ЦП и соединяют чипсеты или кристаллы с помощью межсоединений. Это означает, что не каждое ядро имеет одинаковый путь к каждому модулю ОЗУ, и даже внутри одного сокета есть предпочтительные пути. Чем больше трафика проходит через межсоединения сокетов, тем сильнее растет Латентность и накладные расходы на когерентность. Поэтому я проверяю, сколько каналов памяти активны на каждый узел, все ли слоты DIMM оснащены симметрично и как узлы соединены на материнской плате. Функции Sub-NUMA, которые разделяют узлы на более мелкие домены, могут устранить горячие точки, если рабочие нагрузки четко сегментированы. Я также наблюдаю за Топология L3: Если потоки и их данные находятся в разных доменах кэша, то только передача кэша значительно снижает производительность. Простой тест пропускной способности и обзор топологии быстро покажут, обеспечивает ли платформа ожидаемую локальность или межсоединения становятся узким местом.
Опции прошивки и BIOS с эффектом
В BIOS я убеждаюсь, что Чередование узлов отключена, чтобы структура NUMA оставалась видимой. Я целенаправленно использую суб-NUMA-кластеризацию или аналогичные режимы, когда рабочие нагрузки имеют много средних по размеру, четко разделенных объемов работы. Для обеспечения стабильной задержки я выбираю энергетические профили, ориентированные на производительность, и уменьшаю более глубокие C-состояния и избегайте агрессивного парковки ядра. Я оптимизирую размещение памяти для полной Пропускная способность канала памяти; несимметричные конфигурации DIMM напрямую влияют на пропускную способность и время ожидания. Я также проверяю опции Prefetcher и RAS: некоторые механизмы защиты увеличивают задержку, не влияя на рабочую нагрузку. Важно: каждую настройку BIOS я тестирую с реальной нагрузкой, поскольку микроэффекты, вызванные кэшами и межсоединениями, часто проявляются только под нагрузкой.
Настройка гостевой ОС и среды выполнения: от First-Touch до Huge Pages
В гостях я использую первое касание-Распределение в мою пользу: потоки инициализируют „свою“ память, чтобы страницы создавались локально. В Linux я включаю или отключаю автоматический баланс NUMA в зависимости от рабочей нагрузки; системы, связанные с базами данных, часто выигрывают от стабильной привязки, в то время как распределенные веб-рабочие могут справиться с небольшими миграциями. С помощью numactl или Task-Pinning я привязываю службы к узлам и определяю membind-Правила. Огромные страницы уменьшаю давление TLB; для баз данных, критичных к задержкам, я предпочитаю статические огромные страницы и теплую память (Pre-Touch), чтобы избежать пиков ошибок страниц. Прозрачные огромные страницы я использую в зависимости от движка на „madvise“ или отключаю, если они создают задержки дефрагментации. Я управляю Связь с IRQ и распределяю сетевые и NVMe-прерывания по соответствующим узлам; RPS/XPS и множественные очереди помогают поддерживать согласованность путей передачи данных. В Windows я использую группы процессоров и Soft-NUMA в стеке, обеспечиваю „Lock Pages in Memory“ для ресурсоемких служб и активирую Server-GC в .NET. Для JVM я использую эвристику с учетом NUMA, pre-touche Heaps и управляю аффинностью потоков, чтобы GC и Worker использовали одни и те же узлы.
Четкое выравнивание настроек, специфичных для гипервизора
Я подхожу Топология vNUMA к физической структуре. Я выбираю параметры „Sockets“, „Cores per Socket“ и „Threads per Core“ таким образом, чтобы гипервизор не разбивал виртуальную машину по узлам. Для чувствительных к задержкам экземпляров я резервирую ОЗУ, чтобы не возникали явления ballooning и swapping, и обеспечиваю ресурсы pCPU с помощью аффинности или подходящих опций планировщика. Внимание при горячем добавлении CPU или памяти: многие платформы деактивируют vNUMA в гостевой системе, что приводит к скрытому удаленному доступу. Я планирую живую миграцию таким образом, чтобы целевые хосты имели совместимую топологию NUMA, и после миграции даю виртуальным машинам время для локальность страницы перестроить (Pre-Touch, Warmlauf). В средах KVM я использую опции настройки NUMA и cpuset-Cgroups; в других гипервизорах инструменты exstop/подобные помогают видеть распределение vCPU и удары по узлам в режиме реального времени.
Не упускайте возможности PCIe и локальности ввода-вывода
Я организую NVMe-диски, HBA и NIC к узлу, на котором работают вычислительные потоки. Очереди SR-IOV или vNIC я связываю с ядрами того же узла и соответствующим образом управляю прерываниями. Для высоких скоростей пакетов я масштабирую очереди приема/передачи и распределяю их равномерно по локальным ядрам. В случае стеков хранения я слежу за тем, чтобы рабочие потоки для отправки и завершения ввода-вывода работали на одном узле, чтобы путь данных не проходил через межсоединение. Я также планирую мультипуть и программный RAID с учетом специфики узла; „более короткий“ путь почти всегда превосходит „более широкий“ путь с внешними доступами. Таким образом, я уменьшаю джиттер и при нагрузке ввода-вывода привожу в соответствие время процессора туда, где она будет эффективна.
Планирование емкости, перерасход ресурсов и функции памяти
Я предпочитаю выполнять рабочие нагрузки, ориентированные на задержку, без Overcommit на RAM и умеренно на vCPU. Баллонирование, сжатие и своп гипервизора генерируют посторонние обращения или пики ошибок страниц — именно этого я и хочу избежать. Прозрачное совместное использование страниц в многих конфигурациях неэффективно и может затушевать реальную локальность. Я калибрую смесь виртуальных машин таким образом, чтобы несколько экземпляров, требующих большой пропускной способности памяти, не сталкивались на одном узле. Для движков в памяти я планирую щедрые Бронирование и, где это целесообразно, Huge Pages в гостевой системе, которые гипервизор может пропускать. Таким образом, частота попаданий в TLB и время доступа остаются предсказуемыми.
Живая миграция и высокая доступность
Я принимаю во внимание, что Миграция временно уничтожаю локальность страниц виртуальной машины. После перемещения я прогреваю критические кучи и запускаю фоновые задания для повторного создания хотсетов. Я планирую целевые хосты с аналогичной топологией NUMA, чтобы не пришлось заново настраивать vNUMA. Для случаев HA с гетерогенным оборудованием я устанавливаю политики: либо я кратковременно принимаю более высокую задержку, либо я отдаю приоритет хостам с совместимым размером узла. Важно наблюдение после миграции: если доля удаленных страниц увеличивается, я корректирую аффинности или запускаю пре-фейлтинг, пока Местность снова подходит.
Практические диагностические шаблоны
Я распознаю типичные проблемы NUMA по нескольким признакам: процессор „перегревается“, но Инструкции по циклу остаются низкими; задержка скачет волнами; отдельные потоки блокируются при доступе к памяти, хотя ядра свободны. В таких случаях я смотрю на удаленные обращения, загрузку межсоединений, промахи TLB и распределение активных потоков по узлам. Я соотношу нагрузку прерываний с ядрами, которые поддерживают приложение, и проверяю, не происходит ли постоянная инвалидация кэшей между узлами. Простой контрольный тест — уменьшить виртуальную машину до одного узла: если задержки сразу уменьшаются, то причиной было спанирование или планирование. Аналогичным образом, специальные тесты выявляют пропускную способность ОЗУ на каждый узел и показывают, тормозит ли установка DIMM или опции BIOS.
Практический чек-лист
- Определение топологии: узлы, каналы памяти, распределение PCIe, домены кэша
- Проверить BIOS: Node Interleaving выключен, энергетический профиль Performance, C-States flat
- Обрезка виртуальных машин: vCPU на виртуальную машину ≤ размер узла, vNUMA корректно, учитывайте горячее добавление
- Защита ОЗУ: резервирование для рабочих нагрузок с задержками, огромные страницы, где это целесообразно
- Установка аффинности: привязка потоков, IRQ и очередей ввода-вывода к одному и тому же узлу
- Контейнеры/подсистемы: использование аффинности узлов, менеджера ЦП и топологической осведомленности
- Целенаправленное напряжение: сопровождение крупных инстансов с помощью политик и мониторинга
- Планирование миграции: подходящая целевая топология, предварительное касание куч, наблюдение за локальностью
- Улучшение мониторинга: удаленный доступ, пропускная способность на узел, загрузка межсетевого соединения
- Регулярное тестирование: проверка пропускной способности/задержки после смены прошивки или хоста
