NUMA (Non-Uniform Memory Access — «неравномерный доступ к памяти» или Non-Uniform Memory Architecture — «Архитектура с неравномерной памятью») — схема реализации компьютерной памяти, используемая в мультипроцессорных системах, когда время доступа к памяти определяется её расположением по отношению к процессору.
Содержание
NUMA с когерентностью кэш-памяти (ccNUMA) [ править | править код ]
Системы NUMA состоят из однородных базовых узлов, содержащих небольшое число процессоров с модулями основной памяти.
Практически все архитектуры ЦПУ используют небольшое количество очень быстрой неразделяемой памяти, известной как кэш, который ускоряет обращение к часто требуемым данным. В NUMA поддержка когерентности через разделяемую память даёт существенное преимущество в производительности.
Хотя системы с некогерентным доступом к NUMA проще проектировать и создавать, становится предельно сложно создавать программы в классической модели архитектуры фон Неймана. В результате, все продаваемые NUMA-компьютеры используют специальные аппаратные решения для достижения когерентности кеша и классифицируются как кеш-когерентные системы с распределенной разделяемой памятью, или ccNUMA.
Как правило, существует межпроцессорное взаимодействие между контроллерами кэша для сохранения согласованной картины памяти (когерентность памяти), когда более чем один кэш хранит одну и ту же ячейку памяти. Именно поэтому ccNUMA-платформы теряют в производительности, когда несколько процессоров подряд пытаются получить доступ к одному блоку памяти. Операционная система, поддерживающая NUMA, пытается уменьшить частоту доступа такого типа путём перераспределения процессоров и памяти таким способом, чтобы избежать гонок и блокировки.
Примером многопроцессорных машин с архитектурой ccNUMA может являться серия машин компании Silicon Graphics SGI Origin 2000 ( англ. ) . Суперкомпьютер ASCI Blue Mountain — один из самых мощных суперкомпьютеров 1999 года [1] — представлял собой массово-параллельный кластер из 48 машин SGI Origin 2000 по 128 процессоров в каждой [ источник не указан 1922 дня ] .
Сегодня для большинства серверных нагрузок наиболее узким местом с точки зрения производительности является подсистема памяти. Основными сдерживающим фактором этой производительности являются пропускная способность шины памяти (как правило её частота ниже, чем половина частоты ядра процессора), а также задержка при выполнении адресации на микросхемах памяти. Получение строки данных из оперативной памяти в среднем может занимать до нескольких тысяч тактов процессора, во время которых он фактически простаивает. Для решения данной проблемы давно используется техника введения дополнительных уровней быстродействующей памяти (кэш), в которые заранее подгружаются необходимые строки из оперативной памяти.
Использование многопроцессорных и многоядерных систем подразумевает еще больше проблем с доступом к памяти. Разделение шины памяти между несколькими процессорами еще сильнее снижает скорость получения данных из памяти. Кроме того, возникают новые сложности, связанные с обеспечением когерентности кэша процессоров. С инженерной точки зрения одним из простейших подходов к ускорению пропускной способности доступа к памяти в многопроцессорных системах является технология NUMA («Non-Uniform Memory Access» или «Non-Uniform Memory Architecture»). В этом случае у каждого процессора есть «своя часть» оперативной памяти, к которой он получает доступ через выделенный контроллер. При этом к памяти, привязанной к другим процессорам, можно получить доступ через «чужой» контроллер. Естественно, скорость получения данных при обращении к «чужой» памяти будет значительно ниже, чем при обращении к «своей». Накладные расходы, связанные с обеспечением когерентности кэшей, также повышают задержку при доступе к памяти другого процессора.
Современные серверные платформы на базе процессоров Intel и AMD используют NUMA с помощью технологий QPI и HyperTransport соответственно. Кроме того, существует технология IBM Multinode, которая позволяет задействовать NUMA на более высоком уровне путем объединения нескольких серверов (уже использующих NUMA) на коммутаторе. Примером систем, реализующих NUMA, являются HP ProLiant DL785 G5/G6 и IBM x3850 M2.
Серверные операционные системы, поддерживающие NUMA, — такие, как Windows Sever 2008 и Windows Server 2008 R2 — должны оптимизировать использование процессорами памяти, доступной для них наиболее быстро. Что происходит в данном случае с виртуальными машинами?
Мы знаем, что Hyper-V не использует жесткую привязку к физическому процессору (Processor affinity). Виртуальная машина использует те логические процессоры, которые в настоящее время свободны и предоставляются гипервизору постановщиком ресурсов (Scheduler). Но при этом каждая виртуальная машина имеет специальную характеристику для задания «узла NUMA». Она позволяет гипервизору указать, с каких процессоров и с какой шины памяти будут использоваться ресурсы для данной ВМ.
Этот параметр задаётся при каждом включении виртуальной машины, получая ссылку на наиболее свободный на момет её запуска узел. В случае недостатка ресурсов в «своём» узле NUMA, гипервизор начинает предоставлять виртуальной машине ресурсы другого узла. Поэтому технически могут возникать ситуации, в которых виртуальные машины используют ресурсы нескольких узлов NUMA одновременно. Чтобы предотвратить такое неэффективное использование ресурсов, администратор может в явном виде задать предпочитаемый узел NUMA для каждой виртуальной машины. При этом вы можете в любой момент проверить, какой узел использует виртуальная машина.
В моём примере созданы четыре виртуальным машины.
- Test-1 с двумя виртуальными процессорами и 3 ГБ памяти;
- Test-2 с четырьмя виртуальными процессорами и 4 ГБ памяти;
- Test-3 с двумя виртуальными процессорами и 3 ГБ памяти;
- Test-4 с одним виртуальным процессором и 1 ГБ памяти.
Если я запущу все виртуальные машины и открою Performance Monitor, то в строке «Preferred NUMA Node Index» я увижу, на каком из узлов NUMA запущена виртуальная машина. В нашем случае гипервизор сбалансировано распределил четыре виртуальных машины между двумя узлами NUMA.
Узлы NUMA нумеруются с нуля, две виртуальных машины разместились на узле 0, а две на узле 1. Причем используемое количество логических процессоров и памяти суммарно на каждом из узлов NUMA максимально схоже — так работает балансировка.
Теперь предположим, что виртуальная машина Test-2 , которой мы предоставили наибольшее количество процессоров и памяти, в действительности требует большей производительности чем остальные. И что мы бы хотели разместить её на отдельном узле NUMA, оставив все прочием машины на другом.
Мой коллега из Windows Perfomance Team разместил в своём блоге сценарий Powershell, который позволяет явно указывать узел NUMA для виртуальной машины. На всякий случай также прикладываю файл со сценарием к этой статье. Используя этот сценарий, я в явном виде укажу виртуальной машине Test-2 всегда запускаться на узле 0: numa.ps1 /set test-2 0 . А виртуальные машины Test-1 , Test-3 и Test-4 будут запускаться на узле 1: numa.ps1 /set test-1 1 , numa.ps1 /set test-3 1 , numa.ps1 /set test-4 1 . Изменение привязки к узлу NUMA работает только после включения виртуальной машины. Если виртуальная машина была включена, вам потребуется перезапустить её.
Теперь виртуальная машина Test-2 исключительно занимает узел 0. Заданное предпочтение узла NUMA совместимо с Live Migration и Quick Migration. Переместив такую виртуальную машину на другой узел кластера, вы увидите, что привязка к конкретному узлу NUMA «переехала» вместе с машиной.
К описанной настройке следует подходить осторожно. Надо понимать, что если вы жёстко задали всем виртуальным машинам использовать конкретный узел NUMA, и они используют всю его память или полностью загружают ресурсы процессора, то уже никакой механизм автоматически не перенесет эти машины на другой узел NUMA.
NUMA — это короткое слово, которое периодически замечаешь то там, то тут. В настройках BIOS, в логах операционной системы и т.д. Понимаешь, что оно как-то связанно с многопроцессорными системами, но на что именно влияет и зачем нужно, — эти вопросы практически всегда остаются без ответа. В большинстве случаев, не бывает особой нужды детально разбираться в этих тонкостях работы компьютера. Как известно, человек — создание ленивое, а следовательно: без нужды ничего делать не будет. Работает — значит не трогай… пусть дальше работает. Это девиз многих системных администраторов, и до недавнего времени мы тоже этим от многих других не отличались. Естественно, мы старались что-то оптимизировать, более корректно настраивать многие компоненты операционной системы и серверов. Но мы не пытались оптимизировать абсолютно все. Не факт, что усилия, потраченные на оптимизацию, хоть как-то окупятся.
Это продолжалось до тех пор, пока мы не столкнулись со странным поведением сервера, которое было крайне сложно объяснить. У сервера периодически переставала работать дисковая подсистема, из системы просто исчезал RAID контроллер. Это делало сервер неработоспособным. После перезагрузки нормальная работа системы восстанавливалась. RAID контроллер снова появлялся и работал исправно, как будто ничего и не происходило. Замена RAID контроллера, установка его в другой слот PCI-X, а также замена материнской платы, процессоров, блоков питания, — ничего не давало результатов. Сервер продолжал работать нестабильно. Что мы только не делали — сервер продолжал падать с завидной регулярностью. От одного раза в день до нескольких раз за час. Спрогнозировать дату падения и объяснить, с чем оно связано, было крайне сложно. Наблюдая за графиками загрузки сервера, мы не понимали, в чем проблема. Проблемы появлялись и при маленькой нагрузке на процессор, и при большой. Ответ был найден случайно, в процессе перебора всего подряд. Причиной сбоев оказалось некорректное распределение оперативной памяти между процессорами. Я случайно, собирая информацию о системе, посмотрел на топологию NUMA. Оказалось, что основная масса процессов в системе выполняет дальний доступ к памяти. Это заставило меня обратить внимание на то, что поставщик, из расчета на апгрейд (модернизацию), вместо установки 6-и планок памяти, установил 3, но вдвое большего объема. Как следствие, планки были установлены только в слоты одного процессора. И, по воле случая, первый процессор в системе остался без планок памяти. Так случайный взгляд, брошенный на вещи, на которые мы никогда не обращали внимание, помог выявить проблему.
Так что же такое NUMA? Non-Uniform Memory Access — это «неравномерный доступ к памяти». Так гласит Википедия. Простым языком: это способ взаимодействия одного процессора с блоками памяти второго процессора. Это умное распределение памяти между процессами (условно — программами) в ОС. NUMA помогает распределить процессы в системе так, чтобы они получали области оперативной памяти, расположенные максимально близко к процессорам, на которых они работают. В такой ситуации, как у нас, программы (процессы), запущенные на процессоре без оперативной памяти, использовали так называемый “дальний доступ”. Другими словами: доступ осуществлялся через контроллер на другом процессоре. Все бы ничего и система linux давно умеет решать подобные проблемы. Априори программы (процессы) размещаются на процессоре с оперативной памятью. Но мы не учли одного фактора. А именно: систему виртуализации XEN. Она самостоятельно назначает соответствие виртуального процессора для виртуальной машины физическому (реальному) процессору в системе. Усугубляет ситуацию тот факт, что хост-система (управляющая) является такой же виртуальной машиной, как и другие. И только к ней подключены устройства, такие как: контроллер дисков, сетевая карта и т.д. По-умолчанию, любой виртуальный процессор может оказаться на любом физическом. Зачастую, в хост-системе первый виртуальный процессор соответствуют первому физическому процессору. И, поскольку на виртуальной машине с точки зрения NUMA все процессоры и вся память локальны, хост-система размещает на первом процессоре все прерывания и процессы для работы с устройствами. А если этот процессор не имеет подключенной оперативной памяти, то это не только снижает производительность системы, но и позволяет возникнуть аварийной ситуации. Плюс ко всему, этому первому физическому процессору могут быть назначены несколько виртуальных. А следовательно, за время (ресурсы) первого процессора будут конкурировать несколько виртуальных машин. Установка приоритета доступа к процессорному времени для хост-системы несколько улучшает ситуацию, но не решает проблему полностью. В процессе работы ввиду нехватки процессорного времени для хост-системы происходят сбои и шина pci переинициализируется. В какой-то момент превышается предел ожидания ответа, заложенный в драйвер RAID контроллера, и система констатирует факт его потери. Изюминкой ситуации является тот факт, что проблема появляется только при определенной нагрузке. Как только мы убираем все виртуальные машины с этого сервера, он начинает стабильно работать.
Решением оказалось принудительное перераспределение процессоров между виртуальными машинами. Так, чтобы первый виртуальный процессор на хост-системе был на физическом процессоре, к которому подключена оперативная память. К тому же мы выделили одно физическое ядро процессора с памятью эксклюзивно для хост-системы. Это позволило избежать конкуренции с другими виртуальными машинами. И вуаля! Система уже более месяца работает стабильно. Но это не все! Также существенно увеличилась скорость работы с дисковой подсистемой. Это решение не ново и часто описывается на многих специализированных ресурсах, но в программных продуктах, используемых для автоматизации VPS-хостинга, оно почему-то не учитывается в принципе. На данный момент мы более не покупаем системы без минимального набора оперативной памяти для всех процессоров. Также мы провели эксперимент с системой, у которой был полный комплект памяти. Выделили одно ядро физического процессора для хост-системы и получили прирост скорости работы дисковой подсистемы. Теперь мы работаем над тем, чтобы автоматизировать подобные настройки на всех наших серверах. Это позволит, не меняя аппаратного обеспечения, повысить производительность дисковой подсистемы на наших серверах.