Перейти к содержимому 
Серверы NUMA Nodes создают локальные доступы к памяти для каждого сокета и таким образом заметно повышают эффективность больших хостинговых систем. Я покажу, как эта архитектура уменьшает задержки, увеличивает пропускную способность и тем самым Рабочие нагрузки Лучше масштабируется на корпоративных серверах.
Центральные пункты
- Локальность памяти уменьшает время ожидания и сокращает удаленный доступ.
- Масштабируемость на многих ядрах без узких мест на шине памяти.
- Осведомленность о NUMA в ядре, гипервизоре и приложениях обеспечивает скорость.
- Планирование количество виртуальных машин/контейнеров на одном узле предотвращает возникновение трешинга.
- Мониторинг С помощью numastat/perf можно обнаружить "горячие точки".
Что такое серверы с узлами NUMA?
Я полагаюсь на архитектуру, в которой каждый сокет имеет свою собственную локальную область памяти в качестве Узел NUMA получает. Это означает, что ядро в первую очередь обращается к быстрой, близлежащей оперативной памяти и избегает более медленной, удаленной памяти. Доступ через межсоединения, такие как Infinity Fabric или UPI, по-прежнему возможен, но он требует дополнительных затрат времени.
В отличие от UMA, здесь время доступа варьируется, что напрямую влияет на Латентность и пропускной способности. Крупные системы объединяют такое количество ядер, что при этом не происходит коллапса на шине памяти. Легкое для понимания введение обеспечивается компактным Архитектура NUMA в хостинге.
Локальность памяти в хостинге
Я привязываю процессы и память к одному узлу, чтобы пути передачи данных оставались короткими и Кэш-хиты увеличиваются. Такая локальность памяти оказывает немедленное и заметное влияние на веб-серверы, PHP-FPM и базы данных. Я отодвигаю удаленный доступ, чтобы в секунду обрабатывалось больше запросов.
Запланированные привязки к процессору и памяти предотвращают блуждание потоков по узлам и Thrashing триггер. Для динамических настроек я тестирую подходы к балансировке NUMA, которые оптимизируют доступ с течением времени; более подробное введение можно найти здесь Балансировка NUMA. Таким образом, я сохраняю низкую задержку и использую ядра более эффективно.
Почему NUMA имеет значение для больших хостинговых систем
На крупных хостинговых платформах одновременно размещается множество веб-сайтов, что требует короткого времени отклика. Пик-трафик. NUMA повышает вероятность того, что данные будут находиться рядом с исполняющим ядром, а не путешествовать по межсоединениям. Именно здесь магазины, API и CMS получают важнейшие миллисекунды.
Таким образом, я обеспечиваю более высокую плотность на хосте без ущерба для производительности и сохраняю Время работы-пункты назначения легче. Даже во время пиков трафика время отклика остается более плавным, так как нагрузка на удаленные устройства меньше. Это напрямую окупается улучшением качества обслуживания пользователей и снижением количества отмен.
Технология на практике
Я прочитал топологию с помощью lscpu и numactl --hardware на узлы, ядра и расположение оперативной памяти. Затем я связываю рабочие нагрузки с numactl --cpunodebind и --membind. Гипервизоры, такие как KVM, и современные ядра Linux распознают топологию и уже составляют выгодное расписание.
В многосокетных системах я обращаю внимание на пропускную способность межсоединений и количество RAM-каналы на узел. Приложения с большим объемом кэш-памяти я размещаю локально на узле. Для сервисов со смешанными шаблонами я использую чередующуюся память, если тесты постоянно получают от этого пользу.
Кроме того, я оцениваю с numactl --hardware die расстояния между узлами off: Низкие значения между соседними узлами указывают на более быстрый удаленный доступ, но все равно увеличивают задержку по сравнению с локальной оперативной памятью. Обратите внимание, что --mempolicy=preferred дистанционно с помощью давления на память, в то время как --membind является строгим и приводит к отказу выделения в случае сомнений. Я использую это в зависимости от критичности рабочих нагрузок.
Если процессы создают потоки динамически, я устанавливаю перед запуском набор задач- или cset-маски, чтобы новые потоки автоматически создавались в правильных CPU-домен. Я планирую весь путь во время развертывания: Рабочие, потоки ввода-вывода, сборщики мусора и любые фоновые задания получают согласованную привязку, чтобы не было скрытых межузловых путей.
Ключевые показатели эффективности в сравнении
Я оцениваю оптимизацию NUMA по задержкам и пропускной способности, CPU-использование и масштабирование. Каждая метрика показывает, эффективна ли локальность или преобладает удаленный доступ. Постоянные тесты под нагрузкой дают четкое направление для следующих шагов по настройке.
В следующей таблице показаны типичные размеры хостинговых рабочих нагрузок для веб-служб и баз данных; она иллюстрирует влияние локальных Доступы против удаленного доступа.
| Метрики | Без оптимизации NUMA | С NUMA и локальностью памяти |
|---|---|---|
| Задержка (нс) | 200-500 | 50–100 |
| Пропускная способность (запрос/с) | 10.000 | 25.000+ |
| Загрузка процессора (%) | 90 | 60 |
| Масштабируемость (ядра) | до 64 | 512+ |
Я постоянно измеряю и сравниваю. Профили до и после корректировки. Воспроизводимые контрольные показатели важны для того, чтобы эффект не казался случайным. Так я получаю конкретные, надежные показатели для продуктивной работы.
Особенно значимы процентили, такие как p95/p99, а не просто средние значения. Если высокие процентили заметно снижаются после выравнивания удаленных доступов, значит, платформа более стабильна под нагрузкой. Я также проверяю показатели промахов LLC, контекстных переключений и длина очереди на выполнение на узел, чтобы правильно распределить эффекты планирования и кэширования.
Проблемы и передовой опыт
NUMA Thrashing возникает, когда потоки перемещаются между узлами и постоянно Память запрос. Против этого я использую фиксированное размещение потоков, последовательное связывание памяти и лимиты для каждого сервиса. Четкое назначение заметно снижает удаленный трафик.
В качестве инструментов тестирования я использую numastat, перфект и события ядра в Горячие точки обнаружить. Регулярный мониторинг показывает, не попал ли пул не в тот узел или не распределена ли ВМ. Предпринимая небольшие запланированные шаги, я минимизирую риск и обеспечиваю постоянный прогресс.
Параметры ядра и BIOS/UEFI
Я проверяю настройки BIOS/UEFI, такие как кластеризация sub-NUMA или разделение узлов на сокеты. Более тонкое разделение может усилить локальность, но требует более жестких привязок. Обычно я отключаю глобальное чередование памяти, чтобы разница между локальной и удаленной памятью была минимальной. Память остаются видимыми, и планировщик может принимать разумные решения.
На стороне Linux я установил kernel.numa_balancing сознательно. Для жестких HPC-нагрузок или нагрузок с задержками я отключаю автоматическую балансировку (echo 0 > /proc/sys/kernel/numa_balancing), для смешанных рабочих нагрузок я тестирую его в сочетании с четкими привязанностями процессора. vm.zone_reclaim_mode Я установил консервативный параметр, чтобы узлы не слишком активно возвращали себе свои страницы и не провоцировали ненужные возвраты.
Для баз данных с большим объемом памяти я планирую HugePages на узел. Прозрачные огромные страницы (THP) может колебаться; я предпочитаю использовать статические HugePages и связывать их узлово-локально. Это уменьшает количество пропусков TLB и стабилизирует задержку. Я также контролирую свопинг с помощью vm.swappiness близка к 0, чтобы горячие пути не попадали в своп.
Я сопоставляю прерывания с топологией: irqbalance чтобы прерывания сетевых карт заканчивались на процессорах того же узла, на котором работают соответствующие рабочие. Сетевые стеки с RPS/RFS распределять пакеты в соответствии с масками процессора; я установил эти маски в соответствии с положением рабочего, чтобы избежать перекрестных путей узлов в плоскости данных.
Для твердотельных накопителей NVMe я распределяю очереди по узлам и привязываю потоки ввода-вывода локально. Таким образом, базы данных, кэш и метаданные файловой системы проходят по кратчайшим цепочкам задержек от процессора к оперативной памяти и контроллеру хранилища. Для постоянных журналов или журналов с опережением записи я уделяю особое внимание чистому родству узлов, поскольку оно напрямую влияет на время отклика.
Конфигурация в общих стеках
Я создаю пулы PHP FPM таким образом, что рабочие на Узел и определяю размер пула в соответствии с количеством ядер. Для NGINX или Apache я привязываю интенсивные процессы ввода-вывода к тому же месту, что и кэши. Базы данных, такие как PostgreSQL или MySQL, получают фиксированные HugePages на узел.
На уровне виртуализации я создаю компоновку vCPU, соответствующую физической Макет на. Я использую именно CPU affinity, краткое руководство находится здесь Сродство к процессору. Это позволяет предотвратить излишнюю нагрузку на межсоединения.
Модели рабочей нагрузки: веб, кэш и базы данных
Веб-серверы и PHP-FPM выигрывают, если сокеты, рабочие и кэши слушателей находятся в одном домене NUMA. Я масштабирую независимо для каждого узла: отдельные группы процессов на каждом узле со своей маской процессора и своей общей областью памяти. Это предотвращает прохождение кэшей сессий, OPCache или локальных FastCGI-труб через интерконнект.
В системах Redis/Memcached я использую несколько экземпляров, по одному на узел, вместо одного большого экземпляра на обоих сокетах. Это позволяет сохранить локальность хэш-бакетов и слэбов. Для Elasticsearch или аналогичных поисковых систем я намеренно назначаю шарды узлам и держу потоки запросов и ввода на той же странице, что и соответствующие области файлового и страничного кэша.
С помощью PostgreSQL я разделяю shared_buffers и рабочие пулы на сегменты узлов, разделяя экземпляры или службы на узел. Я масштабирую InnoDB с помощью innodb_buffer_pool_instances и следить за тем, чтобы потоки пула оставались в пределах узла. Я отдельно слежу за контрольными указателями, писателями WAL и автовакуумом, поскольку они часто генерируют нежелательные удаленные доступы.
Для stateful-сервисов я держу фоновые задания (уплотнение, анализ, реиндексация) временно и топологически отделенными от горячих путей. При необходимости я использую numactl --preferred, чтобы обеспечить более плавное перемещение нагрузки без полной жесткости --membind чтобы обеспечить исполнение.
Планирование мощностей и затраты
Я рассчитываю TDP, каналы оперативной памяти и желаемые плотность на узел перед перемещением рабочих нагрузок. Двухсокетная система с высокой долей оперативной памяти на узел часто обеспечивает наилучшее значение евро за запрос. Экономия видна, когда на хосте размещается больше ВМ с одинаковым временем отклика.
Например, переход на размещение с учетом NUMA может увеличить количество хостов на двузначную величину. Проценты уменьшить. Даже с учетом дополнительных расходов в несколько сотен евро на узел в оперативной памяти баланс положительный. Расчет работает, если я сопоставляю измерения с текущими операционными расходами в евро.
Я также учитываю затраты на электроэнергию: локальность сокращает время работы процессора на один запрос, что заметно снижает потребление. Поэтому при определении размеров мастерских я оцениваю не только пиковые запросы/с, но и кВт-ч/1000 запросов на топологию. Такое представление делает решения о более высокой плотности и дополнительных сокетах более осязаемыми.
vNUMA и живая миграция на практике
В виртуальных средах я создаю топологию vNUMA в соответствии с физической структурой. Я группирую vCPU ВМ на vNode и включаю выделенную оперативную память. Таким образом, я избегаю того, чтобы предположительно маленькая ВМ распространялась по обоим сокетам и создавала удаленные доступы.
Я последовательно вывожу процессы QEMU и их потоки ввода-вывода, включая iothread и vhost-задачи. Я храню HugePages на узле в качестве резервной памяти, чтобы ВМ использовала одну и ту же локальную память при каждом запуске. Я сознательно планирую компромиссы: Очень строгие стратегии пиннинга могут ограничить живую миграцию; здесь я выбираю между максимальной стабильностью задержки и гибкостью работы.
При использовании overcommit я обращаю внимание на четкие верхние границы: Если оперативной памяти на узле становится мало, я предпочитаю альтернативные стратегии в рамках одной группы ВМ вместо дикого перераспределения между узлами. Я предпочитаю подключать сетевые карты vNIC и диски vDisks к узлу, на котором вычисляются рабочие ВМ, чтобы путь передачи данных оставался последовательным.
NUMA и оркестровка контейнеров
Контейнеры выигрывают, когда запросы, кэш и Данные расположены локально. В Kubernetes я использую подсказки по топологии, чтобы планировщик распределял ядра и память в одном узле. Я защищаю классы QoS и запросы/лимиты, чтобы поды не блуждали бесцельно.
Я тестирую политики для CPU Manager и HugePages до тех пор, пока Латентность и пропускной способности. Устойчивые рабочие нагрузки получают фиксированные узлы, в то время как неустойчивые сервисы масштабируются ближе к границе. Это позволяет платформе оставаться гибкой, не теряя при этом преимуществ локальности.
С помощью статической политики менеджера процессоров я назначаю ядра исключительно и получаю четкие привязки. Менеджер топологии устанавливает приоритеты single-numa-node, чтобы стручки были объединены вместе. Для шлюзов и контроллеров Ingress я распределяю SO_REUSEPORT-слушатель на узел, чтобы трафик планировался локально. Я планирую кэши, sidecars и сегменты общей памяти для каждой группы подсистем так, чтобы они располагались на одном узле NUMA.
Книга бенчмаркинга и мониторинг
Я работаю с фиксированной процедурой для надежного измерения и настройки эффектов NUMA:
- Захват топологии:
lscpu,numactl --hardware, интерконнект и каналы оперативной памяти. - Базовый уровень под нагрузкой: запишите задержки p95/p99, Req/s, профили пропусков CPU и LLC для каждого узла.
- Представьте переплет:
--cpunodebind/--membind, пулов на каждом узле. - Повторное выполнение: та же нагрузка, те же данные, логическое распределение различий.
- Тонкая настройка: сродство прерываний, HugePages, аллокатор памяти, сборка мусора.
- Проверка на регрессию в CI: регулярно повторяйте сценарии, чтобы предотвратить дрейф.
За глубиной я обращаюсь к perf stat и рекордная производительность Обратно, обратите внимание на счетчики удаленного доступа, пропуски LLC и TLB, а также на доли времени в ядре и пользовательской части. numastat предоставляет мне распределение распределений и частоту удаленных сбоев для каждого узла. Такое представление делает шаги по оптимизации воспроизводимыми и приоритетными.
Типы неисправностей и устранение неполадок
Я распознаю типичные антипаттерны по нестабильным задержкам и высокой загрузке процессора без соответствующего роста пропускной способности. Частыми причинами являются слишком широкие маски процессора, глобальный THP без фиксированных HugePages, агрессивное автомасштабирование без привязки к топологии или неудачно распределенный кэш.
Сначала я проверяю, есть ли потоки с ps -eLo pid,psr,psr,cmd и набор задач -p работают там, где должны. Затем я проверяю numastat-счетчики удаленных доступов и сравниваю их с пиками трафика. При необходимости я временно включаю чередование, чтобы выявить узкие места, а затем снова переключаюсь на строгую локальность.
Она также доказала свою состоятельность, a настраивая винтики один за другим: Сначала привязки, затем привязка к прерываниям, затем HugePages и, наконец, тонкая настройка аллокатора памяти. Таким образом, эффекты остаются отслеживаемыми и обратимыми.
Будущие события
Новые межсоединения и CXL расширяют диапазон адресуемых Память и делают раздельную оперативную память более ощутимой. Серверы ARM с большим количеством ядер также используют топологии типа NUMA и требуют такого же внимания к локальности. Тенденция явно движется в сторону еще более тонких стратегий размещения.
Я ожидаю, что планировщики будут более активно интегрировать сигналы NUMA в Реальное время оцените. Затем стеки хостинга автоматически интегрируют подходящие привязки для типичных рабочих нагрузок. Таким образом, локализация становится стандартом, а не специальной мерой.
Краткое резюме
Узлы NUMA Серверные пучки локальные Ресурсы на сокет и значительно сократить пути передачи данных. Я связываю процессы и память вместе, минимизирую удаленный доступ и последовательно измеряю эффект. Это приводит к заметному увеличению задержки, пропускной способности и плотности.
Благодаря чистому распознаванию топологии, умному связыванию и непрерывному Мониторинг Хостинг-провайдеры получают больше пользы от своего оборудования. Те, кто предпринимает эти шаги, неизменно добиваются ускорения работы сайтов, лучшего масштабирования и предсказуемых затрат. Именно это имеет значение в повседневном бизнесе.
