Основные сведения о многоядерном масштабировании на оборудовании NUMA с помощью IIS 8

Каори Савада

Неоднородный доступ к памяти (NUMA) — это современный проект для доступа к памяти компьютера, который был разработан для преодоления ограничений масштабируемости симметричного многопроцессорного архитектуры (SMP). В SMP каждое ядро обращается к собственной шине и собственному центру ввода-вывода. SMP не работает с большим количеством ЦП (или ядер ЦП), так как они становятся конкурентоспособными для доступа к общей шине.

NUMA была разработана для устранения таких узких мест, ограничивая количество ЦП в любой одной шине памяти и подключая их с помощью высокоскоростного соединения. Для использования этих возможностей IIS 8 (которая входит в состав Windows Server 2012) и более поздних версий предлагает функции для повышения производительности на оборудовании NUMA. Это позволяет службам IIS интеллектуально сопрягать рабочие процессы с узлами NUMA и обеспечивать более эффективное использование ЦП.

Новые параметры, связанные с NUMA, в IIS 8

Чтобы предоставить администратору высокий уровень контроля, IIS 8 имеет следующие четыре новые функции и параметры, которые вступают в игру на серверах, поддерживающих оборудование NUMA:

• Соответствие процессоров
• Режим сходства
• Оптимальный выбор NUMA
• Веб-сады

Соответствие процессоров

Сходство процессоров не является новой функцией, но она была улучшена в IIS 8. Атрибуты smpProcessorAffinityMask и smpProcessorAffinityMask2 доступны с iis 7 и позволяют администратору совредить пул приложений с определенным ядром. Их назначение остается прежним с IIS 8, но в IIS 8 были добавлены следующие новые элементы схемы для поддержки более 64 логических процессоров (LPs):

<element name="cpu">
 ...
 <attribute name="smpAffinitized" type="bool" defaultValue="false"/>
 <attribute name="smpProcessorAffinityMask" type="uint" defaultValue="4294967295"/>
 <attribute name="smpProcessorAffinityMask2" type="uint" defaultValue="4294967295"/>
 <attribute name="processorGroup" type="int" defaultValue="0" validationType="integerRange"
 validationParameter="0,2147483647"/>
 ...
</element>

* Выделены изменения для IIS 8.

Примечание

Для поддержки более 64 LPs была представлена новая концепция: группа процессоров. Любой компьютер с более чем 64 LPs имеет более одной группы процессоров по необходимости. Одна группа процессоров — это статический набор LPs и рассматривается как единая сущность планирования. При запуске операционной системы создаются группы процессоров и назначаются им логические процессоры. Группы процессоров нумеруются начиная с 0.

Так как smpProcessorAffinityMask и smpProcessorAffinityMask2 предлагают 64 бит (32), атрибут processorGroup можно использовать для сопоставления пулов приложений в системе с 64 ядрами. Для настройки десятичной маски процессора используются две сходства, а маска процессора с десятичной дробью указывает, к какому ЦП должны быть привязаны рабочие процессы в пуле приложений. Например, если у вас есть компьютер с 64 процессорами и вы хотите включить 8-й, 15-й, 26-й, 32-й, 40-й, 48-й и 60-й процессоры, вычислите шестнадцатеричную маску процессора следующим образом.

Идентификация процессора начинается с 0 справа налево, поэтому в двоичном формате вы будете определять процессоры 8, 15, 26 и 32 для первых 32 процессоров как:

1000 0010 0000 0000 0100 0000 1000 0000

Это число, преобразованное в десятичное, является вашим smpProcessorAffinityMask:

0x82004080

Вы также определите процессоры 40, 48 и 60 для второго набора из 32 процессоров как:

0000 1000 0000 0000 1000 0000 1000 0000

Это число, преобразованное в десятичное значение, является smpProcessorAffinityMask2:

0x8008080

Так как тип этих двух affinity Masks имеет тип uint, то есть 32-разрядное целое число без знака, они предлагают 64 адресуемых бита в общей сложности, что позволяет указать до 64 процессоров. Для поддержки сопоставления пула приложений с более чем 1 группой процессоров или с более чем 64 процессорами, атрибут processorGroup представляет для этих ситуаций. Если вы ссылаетесь на processorGroup с нумерованным 0, соответствующие значения AffinityMask применяются к первой группе, которая нумеруется от 0 до 63. Если вы ссылаетесь на processorGroup 1, то значения маски применяются ко второй, которая нумеруется от 64 до 127. Вы можете указать только одну группу процессоров, чтобы обеспечить соответствие пула приложений lp. В приведенном ниже примере показано, что значения маски применяются только ко второй группе процессоров, которая является группой 1. Любой рабочий процесс в этом пуле приложений никогда не выполняется на LP в первой группе процессоров, которая является группой 0.

Ниже приведен пример настройки для applicationHost.config.

<applicationPools>
   <add name="DefaultAppPool">
      <cpu smpAffinitized="true" smpProcessorAffinityMask="82004080" 
      smpProcessorAffinityMask2="8008080" processorGroup="1" />
   </add>
</appricationPools>

Примечание

Вы можете настроить более двух групп процессоров, даже если процессоров меньше 64 LPs.

https://msdn.microsoft.com/library/ff542298(VS.85).aspx

В этом сценарии некоторые биты атрибутов smpProcessorAffinityMask и smpProcessorAffinityMask2 будут игнорироваться.

На рисунке ниже показано, как настроить маску в диалоговом окне расширенной конфигурации пула приложений.

При использовании этой конфигурации пулы ApplicationPools жестко сопоставлены, что означает, что это не влияет на другие узлы NUMA. В ходе тестирования было показано, что жесткое сходство обеспечивает более высокую пропускную способность, чем мягкое сходство, измеряемое в запросе в секунду (RPS).

Примечание

ProcessorGroup учитывается только в том случае, если она используется с AffinityMasks для ручной привязки процесса к ядру.

Режим сходства

Когда дело доходит до сопоставления процесса с ядром или узлом NUMA, возможны два режима сходства:

1. Жесткое сходство. Процесс сходится с ядром (или ядрами, составляющими узел NUMA), и все потоки процесса выполняются сопоставленным ядром. Потоки не могут выполняться другими ядрами в системе, независимо от того, имеют ли другие ядра дополнительные циклы ЦП или нет. Потоки содержатся в сопоставлении ядра.
2. Мягкое сходство. Процесс связан с ядром (или ядрами, составляющими узел NUMA) в качестве предпочтительного ядра. Когда планируется выполнение потока, сначала учитывается "предпочтительное ядро", однако в зависимости от нагрузки и доступности других ядер в системе поток может быть запланирован на других ядрах в системе. Такое поведение часто описывается как эффект "перелива", при котором потоки "перетекают" в другие ядра, не относящиеся к мягкому сходству.

В IIS 8 появился следующий новый элемент схемы для настройки режимов сходства:

<element name="cpu">
 ...
 <attribute name="numaNodeAffinityMode" type="enum" defaultValue="Soft">
 <enum name="Soft" value="0" />
 <enum name="Hard" value="1" />
 </attribute>
</element>

Администратор также может настроить атрибут numaNodeAffinityMode с помощью Service Manager Интернета.

По умолчанию пулы приложений имеют мягкое сходство, так как это более "прощающая" конфигурация для большинства сценариев. Если вы достаточно продвинуты для интеллектуальной настройки атрибутов smpProcessorAffinityMask и smpProcessorAffinityMask2 , настройка жесткого или мягкого сходства в соответствии с макетом узла системы может повысить производительность.

Оптимальный выбор NUMA

По умолчанию Windows назначает каждый процесс следующему узлу NUMA в системе с помощью простого алгоритма циклического перебора. Это гарантирует, что потоки для любого процесса выполняются в одном узле NUMA по умолчанию везде, где это возможно. Однако IIS 8 включает другой алгоритм планирования, чтобы свести к минимуму доступ к памяти на удаленных узлах NUMA. Оптимальный выбор NUMA относится к функциональным возможностям, в которых IIS 8 выбирает узел NUMA, который должен обеспечить лучшую производительность для рабочего процесса, экземпляр которого будет создан. Существует два варианта в IIS 8 для этой конфигурации:

1. MostAvailableMemory. Алгоритм планирования рабочих процессов, запущенных WAS, который запланировал процесс на узле с наиболее доступной памятью. Это помогает свести к минимуму доступ к памяти на удаленном узле NUMA. Первый рабочий процесс выбирается в зависимости от того, какой узел NUMA имеет наиболее доступную (свободную) память. Остальные рабочие процессы аффинизируются циклическим перебором.

   Примечание

   Атрибут numaNodeAffinityMode применим только к MostAvailableMemory.

2. Планирование Windows. Операционная система по умолчанию назначает каждый процесс следующему узлу NUMA в системе с помощью алгоритма циклического перебора в системе NUMA. Рабочие процессы распределяются равномерно, так как Windows выбирает узел NUMA на основе этого алгоритма циклического перебора и выполняет обратимое сопоставление процессов с узлами NUMA.

   Примечание

   Атрибут numaNodeAffinityMode неприменим к Планированию Windows, так как это не реализация IIS, а сама реализация Windows.

Настройка этих параметров выполняется с помощью новых параметров схемы:

<element name="cpu">
 ... 
 <attribute name="numaNodeAssignment" type="enum"   defaultValue="MostAvailableMemory">
 <enum name="MostAvailableMemory" value="0"/>
 <enum name="WindowsScheduling" value="1"/>
 </attribute >
 ... 
</element>

Администратор может настроить атрибут numaNodeAssignment с помощью интернет-Service Manager.

Как это работает?

Рассмотрим конфигурацию, в которой есть 8 узлов NUMA и веб-сад из 4 процессов. Если для атрибутов numaNodeAssignment задано значение MostAvailableMemory , а узел NUMA 2 выбран в качестве оптимального узла NUMA для первого из 4 процессов и сродствен с, последующие из них будут последовательно сопоставлены с узлами NUMA 3, Node 4 и Node 5:

NUMA0	NUMA1	NUMA2	NUMA3	NUMA4	NUMA5	NUMA6	NUMA7
		IIS w3wp	IIS w3wp	IIS w3wp	IIS w3wp

Аналогичным образом, если узел NUMA 6 выбран для первого из 4 процессов, последующие будут последовательно сродство с узлом NUMA 7, 0 и 1:

NUMA0	NUMA1	NUMA2	NUMA3	NUMA4	NUMA5	NUMA6	NUMA7
IIS w3wp	IIS w3wp					IIS w3wp	IIS w3wp

Веб-сады

Поведение веб-сада в IIS 8 и более поздних версиях также немного изменилось. В СЛУЖБАх IIS 7.5 (которая поставляется вместе с Windows Server 2008 R2) значение атрибута maxProcesses начиналось с 1, а в iis 8 это значение теперь начинается с 0 (хотя значение по умолчанию по-прежнему равно 1!). Вот как это выглядит в схеме:

<element name="processModel">
 ...
 <attribute name="maxProcesses" type="uint" defaultValue="1" validationType="integerRange"
 validationParameter="0,2147483647" />
 ... 
</element>

Естественно, это также можно настроить с помощью графического пользовательского интерфейса:

Если для этой конфигурации задано значение 0 на оборудовании, отличном от NUMA, используется значение по умолчанию 1. Если на оборудовании NUMA задано значение 0, службы IIS будут запускать столько рабочих процессов, сколько узлов NUMA в системе, чтобы между рабочими процессами и узлами NUMA существовало сходство 1:1. В таких системах для параметра maxProcesses следует задать значение 0, чтобы достичь максимальной производительности.