Масштабируемость сетевых ресурсов на высокопроизводительных серверах

Опции документа PDF - A4 849KB (27 страница) Загрузить Adobe® Reader® Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Барри Арндт, аналитик производительности программного обеспечения, IBM

19.02.2008

Распространение высокопроизводительных масштабируемых серверов добавило новый уровень сложности для сетевых ресурсов и производительности системы. Из этой статьи вы узнаете о том, как оптимизировать многоузловую высокопроизводительную систему под Linux®, насчитывающую от 1 до 4 узлов, в которой используются встроенные в системные платы адаптеры Gigabit Ethernet. Мы рассмотрим проблематику масштабирования сетевых ресурсов и дадим советы о том, как избежать трудностей.

Уже немало было написано о настройке, оптимизации и производительности сетевых ресурсов на множестве устройств, платформ и операционных систем, работающих с различными нагрузками. И всё же появление и распространение масштабируемых серверов высокой производительности (например, IBM® eServer™ xSeries® x460 и IBM System x™ 3950) добавило новый уровень сложности для сетевых ресурсов и производительности системы. Например, в расширяемых серверах, производительность которых может наращиваться путём добавления полных шасси (или узлов), расширяемость многоузловых систем становится важной составляющей общей производительности системы.

Конфигурации систем

Испытываемая система представляет собой сервер IBM eServer xSeries 460 из четырёх узлов, работающих под управлением SUSE Linux Enterprise Server 10 for AMD64 and EM64T (x86-64). Каждый из узлов имеет следующую конфигурацию:

• Система: IBM eServer xSeries 460
• Процессор: 4 64-разрядных процессора Intel® Xeon® 7040 с тактовой частотой 3,0 ГГц
• Память: 32 ГБ (8 модулей DIMM по 1 ГБ, распределенных по четырём платам памяти)
• Адаптеры Ethernet: Broadcom 5704 10/100/1000 dual Ethernet, встроенный на системную плату, 64-разрядный, PCI-X 2.0, 266 МГц
• Сетевой драйвер: tg3 c3.49
• Тип сети: 1 Gigabit Ethernet
• Многопоточность: Технология Hyper-Threading

Во всех тестах в качестве источников нагрузки использовались системы IBM System p5™ 550, оснащенные каждая двумя двухпортовыми адаптерами Ethernet и работающие под управлением Red Hat Enterprise Linux 4 Update 4. В испытаниях соединения четырёх узлов также использовалась система IBM eServer xSeries 460 из двух узлов, работающая под управлением SUSE Linux Enterprise Server 10 for AMD64 and EM64T (x86-64). Испытуемая система и источники нагрузки были объединены в сеть с помощью коммутатора Cisco Catalyst 3750G-24TS.

В начало

Методика испытаний

В качестве демонстрационной нагрузки для проверки масштабируемости был выбран тест производительности netperf, а именно, тестирование однонаправленного потока TCP_STREAM. Это было сделано по многим причинам, в том числе в силу его простоты, удобства измерения, стабильности под Linux, широкой распространённости и возможности точного измерения (наряду с другими параметрами) эффективности передачи больших массивов данных. В этом тесте используется простая клиент-серверная модель; соответственно тест содержит два исполняемых файла - netperf и netserver.

Простой тест TCP_STREAM измеряет время передачи данных от системы netperf серверу netserver для определения того, как быстро одна система может отправлять данные, а другая – получать их. Во время выполнения netperf устанавливает с удалённой системой управляющее соединение (по протоколу TCP). Это соединение используется для передачи информации о конфигурации и результатов между системами. Для измерения используется отдельное соединение, во время работы которого по управляющему соединению трафик не передаётся (за исключением трафика, который требуется для работы некоторых функций TCP).

Во всех описываемых здесь испытаниях пропускная способность сети и загрузка процессора измерялись при выполнении сервером IBM eServer xSeries 460 отправки данных по сети (netperf), получения данных (netserver), или обоих процессов одновременно (двунаправленная передача). Пропускная способность между клиентом и сервером регистрировалась на клиентской стороне и приводится в соответствии с показаниями netperf.

Каждый этап испытаний для каждой среды состоял из трёхминутного поточного теста для каждого из 15 размеров отправляемых сообщений, от 64 байт до 256 КБ. В этот диапазон входили сообщения размером 1460 и 1480 байт, чтобы общий размер пакетов был близок соответственно снизу и сверху к максимальному размеру передаваемого блока (maximum transmit unit, MTU), задаваемому по умолчанию (1500 байт), после которого Linux перед отправкой по сети разбивает сообщения на меньшие пакеты. Загрузка процессора измерялось на испытуемой системе и регистрировалось по показаниям утилиты sar (из пакета sysstat) как среднее по системе по времени работы netperf. Вся информация о процессоре и прерываниях также выводилась из данных sar.

В ходе демонстрации возможностей масштабирования параметры конфигурации модифицировались. Их включение и выключение в различных комбинациях приводило к различным результатам. Процессоры, которые могут обрабатывать конкретные прерывания, задаются битовой маской SMP IRQ Affinity /proc/irq/nnn/smp_affinity. Во время инициализации Linux устанавливает значения этой маски по умолчанию. Для динамического распределения аппаратных прерываний по процессорам можно запустить демон irqbalance. Если этот демон включен, он циклически изменяет битовые маски smp_affinity, тем самым выполняя балансировку. Для привязки определенных процессов к процессорам и (или) памяти на определенных узлах можно использовать программу numactl. Механизм объединения сетевых ресурсов Linux предоставляет множество методов агрегирования нескольких сетевых интерфейсов в один логический интерфейс, что может быть полезно на многоузловых серверах.

В начало

Результаты для производительности и масштабируемости

Давайте посмотрим на результаты, полученные для следующих конфигураций:

1. Стандартная: без изменения конфигурации программного обеспечения
2. Стандартная с numactl: то же, что и в предыдущем случае, но для связывания приложений netperf и (или) netserver на испытуемой системе к процессору и памяти соответствующего узла используется numactl
3. Привязка Ethernet SMP IRQ: то же, что в первом случае, но обработка прерываний каждого адаптера Ethernet привязана к процессору того узла, на котором расположен адаптер (irqbalance не использовался)
4. Привязка Ethernet SMP IRQ и numactl: комбинация сред №2 и №3
5. Объединение каналов Ethernet: назначение одного IP-адреса для части или всех адаптеров Ethernet в большой многоузловой системе

Стандартная конфигурация

Тесты в стандартной конфигурации, где параметры программного обеспечения не изменялись. В этой среде при инициализации Linux по умолчанию запускается демон irqbalance. Назначение SMP IRQ не изменялось, также не использовались объединение каналов и numactl.

В первом тесте netserver на масштабируемость использовался один экземпляр netserver для каждого из двух адаптеров Ethernet системной платы первого узла испытуемой системы. Каждый экземпляр netserver прослушивал выделенный порт и адрес IP; IP-адреса всех адаптеров Ethernet находились в различных подсетях, чтобы обеспечить разделение трафика. На удалённых драйверах запускались соответствующие экземпляры netperf, создававшие потоковый трафик от удалённых экземпляров netperf к экземплярам netserver испытуемой системы в конфигурации "один к одному". В ходе испытания измерялась пропускная способность сети и загрузка процессора для 15 различных размеров сообщений, по 3 минуты для каждого размера.

Во втором тесте netserver на масштабируемость использовались все четыре адаптера Ethernet системной платы первых двух узлов, а в третьем тесте использовались все восемь адаптеров Ethernet, расположенных на системных платах всех четырёх узлов. Количество экземпляров netserver для испытуемой системы и удалённых экземпляров netperf увеличивалось соответствующим образом для каждого теста.

На рисунке 1 показаны пропускная способность и загрузка процессора в тестах на масштабируемость netserver при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 1.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

После этого были проведены тесты на масштабируемость netperf. Они были аналогичны тестам для netserver, за исключением того, что netperf запускался на испытуемой системе, а netserver - на удалённых системах.

На рисунке 2 показаны пропускная способность и загрузка процессора в тестах на масштабируемость netperf при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 2.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Наконец, аналогично предыдущим тестам netserver и netperf проводились тесты на двустороннюю масштабируемость. Однако в этом случае использовался только один адаптер Ethernet первой системной платы каждого узла, один экземпляр netperf и один экземпляр netserver. Иначе говоря, на одном адаптере Ethernet проводилось два теста, один netperf и один netserver, и на каждом узле использовался только один адаптер Ethernet. Каждый соответствующий удалённый экземпляр netperf или netserver работал на собственном адаптере Ethernet, обеспечивая максимальный возможный трафик от испытуемой системы и к ней.

На рисунке 3 показаны пропускная способность и загрузка процессора в тестах на двустороннюю масштабируемость при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 3.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Для каждого размера отправляемого сообщения рассчитывалось изменение пропускной способности при масштабировании с 2 адаптеров на 1 узле до 4 адаптеров на 2 узлах. В тестах на масштабируемость netserver эти значения изменялись от 1,647 для сообщений алого размера до 1,944 для сообщений большого размера. Средняя величина для всех значений составляет 1,918. Аналогично для каждого размера отправляемого сообщения рассчитывалось изменение загрузки процессора при масштабировании с 2 адаптеров на 1 узле до 4 адаптеров на 2 узлах. В тестах на масштабируемость netserver эти значения изменялись от 2,770 до 1,623. Средняя величина всех этих значений в этой среде составила 2,417.

Также для каждого размера сообщений рассчитывалось изменение пропускной способности и загрузки процессора при масштабировании с 4 адаптеров на 2 узлах до 8 адаптеров на 4 узлах. Для пропускной способности эти значения изменялись в диапазоне от 1,666 до 1,900 со средним значением 1,847. Изменение загрузки процессора варьировалось от 2,599 до 1,884 при среднем значении 2,386.

Среднее изменение пропускной способности при масштабировании с 2 адаптеров на 1 узел до 8 адаптеров на 4 узла по всем размерам отправляемых сообщений составило 3,542. Среднее изменение загрузки процессора при масштабировании с 2 адаптеров на 1 узел до 8 адаптеров на 4 узла по всем размерам отправляемых сообщений составило 5,755.

В таблице 1 показаны усреднённые расчёты масштабирования для тестов netserver, netperf и двусторонних тестов.

Поскольку в этом ряде испытаний не использовалось назначение SMP IRQ, все прерывания Ethernet обрабатывались процессором, назначенным по умолчанию параметрами /proc/irq/nnn/smp_affinity, которые изменяются командойirqbalance во время инициализации. Данные sar, содержащие такую информацию, как загрузка процессора и количество прерываний на процессор, показывают, что все сетевые прерывания обрабатывались процессорами первого узла, независимо от того, на каком узле расположен адаптер Ethernet. Это добавляло ненужную задержку на переключение между узлами.

В листинге 1 показана часть данных sar из тестов на масштабируемость netserver, когда netserver работал на всех четырёх адаптерах Ethernet на всех четырёх узлах. Данные приведены для размера сообщения 8 КБ и репрезентативны для всех тестов в этой среде. Указанные значения являются средними величинами на трёхминутном испытании.

                
CPU     %user     %nice   %system   %iowait    %steal    %idle
 0      4.50      0.00     70.18      0.00      0.00     25.32
 1      1.89      0.00     88.54      0.00      0.00      9.57
 2      1.68      0.00     70.54      0.00      0.00     27.77
 3      0.66      0.00      4.81      0.00      0.00     94.53
 4      1.90      0.00     80.43      0.00      0.00     17.67
 5      2.44      0.00     82.38      0.00      0.00     15.18
 6      1.79      0.00     70.55      0.00      0.00     27.66
 7      0.55      0.00      5.40      0.00      0.00     94.04
 8      3.91      0.00     67.36      0.00      0.00     28.73
 9      1.66      0.00     82.23      0.00      0.00     16.11
10      0.21      0.00      4.37      0.00      0.00     95.43
11      0.35      0.00      5.53      0.00      0.00     94.12
12      0.13      0.00      1.97      0.00      0.00     97.90
13      0.10      0.00      1.88      0.00      0.00     98.03
14      0.09      0.00      2.14      0.09      0.00     97.68
15      0.07      0.00      1.86      0.89      0.00     97.18
 .
 .      (unlisted values are 0 or near 0)
 .

        eth0     eth1     eth2     eth3     eth4     eth5     eth6     eth7
CPU     i177/s   i185/s   i193/s   i201/s   i209/s   i217/s   i225/s   i233/s

 0   17542.70     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 1       0.00     0.00     0.00     0.00     0.00 19515.86     0.00     0.00
 2       0.00     0.00     0.00 18612.58     0.00     0.00     0.00     0.00
 3       0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 4       0.00     0.00     0.00     0.00 18816.80     0.00     0.00     0.00
 5       0.00     0.00 18545.74     0.00     0.00     0.00     0.00     0.00
 6       0.00     0.00     0.00     0.00     0.00     0.00 18609.16     0.00
 7       0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 8       0.00 17506.10     0.00     0.00     0.00     0.00     0.00     0.00
 9       0.00     0.00     0.00     0.00     0.00     0.00     0.00 18606.14
 .
 .   (unlisted values are 0 or near 0)
 .

Даже несмотря на то, что масштабирование пропускной способности в этой среде было не очень плохим, масштабируемость процессоров резко падала с ростом количества используемых адаптеров Ethernet. Рост загрузки процессоров объясняется ненужными переключениями между узлами для обработки прерываний адаптеров Ethernet вспомогательных узлов процессором основного узла. Данные, собранные в других средах, покажут, что общая пропускная способность в этой среде также страдает.

Стандартная конфигурация с numactl

Тесты на масштабируемость и методика проведения испытаний остались такими же, как и в стандартной конфигурации. Отличие среды в этом случае состоит в использовании numactl для связывания приложений netperf и (или) netserver на испытуемой системе с процессором и памятью соответствующих узлов. Такая связь гарантирует, что приложения будут работать на процессорах того же узла, адаптеры Ethernet которого они используют. numactl вызывается следующим образом:

numactl --cpubind=node --preferred=node netserver

где cpubind=node указывает узел, процессор которого должен выполнять процесс, а preferred=node указывает узел, память которого будет выделяться для этого процесса. Если выделить память на этом узле невозможно, будет использоваться память другого узла.

Тесты netserver, netperf и двунаправленные тесты проводились так же, как и для стандартной конфигурации, сбор данных также проводился аналогичным образом.

На рисунке 4 показана пропускная способность и загрузка процессора в тестах на масштабируемость netserver при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 4.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Тесты на масштабируемость netperf проводились так же, как и в предыдущей среде. На рисунке 5 показана пропускная способность и загрузка процессора в тестах на двустороннюю масштабируемость при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 5.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Двусторонние тесты на масштабируемость проводились так же, как и в предыдущей среде. На рисунке 6 показана пропускная способность и загрузка процессора в тестах на двустороннюю масштабируемость при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 6.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Так же, как и в испытаниях со стандартной конфигурацией, были проведены расчёты и усреднения масштабирования для тестов netserver, netperf и двусторонних тестов при масштабировании адаптеров Ethernet с 1 до 2 узлов, с 2 до 4 узлов и с 1 до 4 узлов. Результаты показаны в таблице 2.

Как и в предыдущих тестах, поскольку в этом ряде испытаний не использовалось назначение SMP IRQ, все прерывания Ethernet обрабатывались процессором, назначенным по умолчанию параметрами /proc/irq/nnn/smp_affinity, которые изменяются во время инициализации командой irqbalance. Данные sar показывают, что все прерывания обрабатывались процессорами первого узла, независимо от того, на каком узле расположен адаптер Ethernet, даже если приложение было привязано к процессору и памяти узла, адаптер Ethernet которого используется, с помощью numactl. На самом деле привязка netperf и (или) netserver к процессорам локальных для используемых адаптеров Ethernet узлов привела к значительному улучшению общей загрузки процессоров, несмотря на то, что прерывания этих адаптеров обрабатывались на других узлах.

В листинге 2 показана часть данных sar из тестов на масштабируемость netserver, когда netserver работал на всех четырёх адаптерах Ethernet на всех четырёх узлах. Данные приведены для размера сообщения 8 КБ и репрезентативны для всех тестов в этой среде. Указанные значения являются средними величинами по трёхминутному испытанию.

                
CPU     %user     %nice   %system   %iowait    %steal    %idle
 0      3.48      0.00     79.71      0.00      0.00     16.81
 1      0.03      0.00     73.55      0.00      0.00     26.42
 2      0.02      0.00     67.80      0.00      0.00     32.18
 3      0.09      0.00      0.08      0.00      0.00     99.83
 4      0.00      0.00     73.59      0.00      0.00     26.41
 5      0.03      0.00     73.14      0.00      0.00     26.83
 6      0.01      0.00     62.52      0.00      0.00     37.47
 7      0.04      0.00      0.07      0.00      0.00     99.89
 8      3.80      0.00     71.70      0.00      0.00     24.51
 9      0.02      0.00     68.80      0.00      0.00     31.19
 .
17      0.69      0.00     92.92      0.00      0.00      6.39
18      0.01      0.00      0.00      0.00      0.00     99.99
19      0.75      0.00     92.90      0.00      0.00      6.36
 .
32      0.77      0.00     93.60      0.00      0.00      5.63
 .
43      0.80      0.00     93.57      0.00      0.00      5.63
 .
49      0.76      0.00     92.91      0.00      0.00      6.34
 .
63      0.35      0.00     93.31      0.00      0.00      6.35


        eth0     eth1     eth2     eth3     eth4     eth5     eth6     eth7
CPU     i177/s   i185/s   i193/s   i201/s   i209/s   i217/s   i225/s   i233/s

0    16990.40     0.00     0.00     0.00     0.00     0.00     0.00     0.00
1        0.00     0.00 11568.49     0.00     0.00     0.00     0.00     0.00
2        0.00     0.00     0.00 13777.11     0.00     0.00     0.00     0.00
3        0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
4        0.00     0.00     0.00     0.00 10657.14     0.00     0.00     0.00
5        0.00     0.00     0.00     0.00     0.00 10653.40     0.00     0.00
6        0.00     0.00     0.00     0.00     0.00     0.00 13474.30     0.00
7        0.00     0.00     0.00     0.00     0.00     0.00     0.00     0.00
8        0.00 16630.13     0.00     0.00     0.00     0.00     0.00     0.00
9        0.00     0.00     0.00     0.00     0.00     0.00     0.00 12092.25
.
.    (unlisted values are 0 or near 0)
.

Обработка сетевых прерываний на узлах, удаленных по отношению к узлу, на котором установлен адаптер Ethernet, - определенно не самое оптимальное решение. В такой среде привязка сетевых приложений с помощью numactl к узлам, на которых установлены адаптеры Ethernet, ухудшает ситуацию. Как показывают данные из этой и предыдущей сред, снижаются пропускная способность, загрузка процессора и общее масштабирование.

Привязка Ethernet SMP IRQ

Тесты на масштабируемость и методика проведения испытаний остались такими же, как и в стандартной конфигурации. Разница между этими средами состоит в том, что в этом случае обработка прерываний каждого адаптера Ethernet привязывалась к процессору того узла, на котором установлен адаптер. Кроме того, в этой конфигурации не использовался irqbalance .

Привязка прерываний к процессору или группе процессоров (аффинизация) выполняется посредством управления битовой маской smp_affinity для конкретного номера прерывания. Эта битовая маска показывает, какой процессор должен обрабатывать заданное прерывание. При аффинизации прерываний сначала нужно остановить демон irqbalance , в противном случае он будет циклически изменять значение smp_affinity. Если это произойдёт, эффект аффинизации будет сведен к нулю, и обработка прерываний адаптеров Ethernet не обязательно будет выполняться на том процессоре, на котором предполагалось. На самом деле обработка прерываний адаптера Ethernet на одном узле может переключиться на процессор другого узла. Чтобы остановить демон irqbalance, выполните команду

killproc -TERM /usr/sbin/irqbalance

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

Чтобы привязать прерывание к процессору или группе процессоров, сначала нужно определить, какой процессор должен обрабатывать прерывание, и соответствующим образом задать битовую маску. Крайний справа бит маски устанавливается для CPU0, следующий для CPU1 и так далее. Для обозначения группы процессоров можно установить несколько битов. После этого задайте значение битовой маски, выполнив следующую команду:

echo bitmask > /proc/irq/IRQ_number/smp_affinity

Например, чтобы привязать обработку прерывания номер 177 к процессорам с 4 по 7 (битовая маска 11110000), выполните:

echo f0 > /proc/irq/177/smp_affinity

Обратите внимание, что в данном исследовании при установке битовой маски smp_affinity для нескольких процессоров сразу наблюдалось следующее поведение: сетевые прерывания всегда обрабатывались первым процессором, указанным в битовой маске. Если в битовых масках двух прерываний установлен один и тот же первый бит, оба прерывания обрабатываются на одном и том же процессоре, указываемом первым битом. Например, если у прерываний двух адаптеров Ethernet установлена битовая маска smp_affinity 0000ffff, прерывания обоих адаптеров будут обрабатываться CPU0. Таким образом, сейчас не следует задавать пересекающиеся битовые маски smp_affinity для прерываний разных адаптеров Ethernet, если, конечно, вы не хотите обрабатывать их на одном процессоре.

Значения битовых масок smp_affinity для этого теста были установлены следующим образом:

first ethernet adapter on first node:	00000000,000000f0
second ethernet adapter on first node:	00000000,0000f000
first ethernet adapter on second node:	00000000,00f00000
second ethernet adapter on second node:	00000000,f0000000
first ethernet adapter on third node:	000000f0,00000000
second ethernet adapter on third node:	0000f000,00000000
first ethernet adapter on fourth node:	00f00000,00000000
second ethernet adapter on fourth node:	f0000000,00000000

Эти установки гарантируют, что прерывания каждого адаптера Ethernet обрабатываются на процессоре того узла, на котором установлен адаптер. Процессор CPU 0 был намеренно оставлен свободным от обработки сетевых прерываний, поскольку обычно он нагружен выполнением многих других задач.

Тесты netserver, netperf и двунаправленные тесты проводились так же, как и для стандартной конфигурации, сбор данных также проводился аналогичным образом. На рисунке 7 показаны пропускная способность и загрузка процессора в тестах на масштабируемость netserver при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 7.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Тесты на масштабируемость netperf проводились так же, как и в предыдущей среде. На рисунке 8 показана пропускная способность и загрузка процессора в тестах на масштабируемость netperf при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 8.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

На рисунке 9 показана пропускная способность и загрузка процессора в тестах на двустороннюю масштабируемость netserver при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы. Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Увеличить рисунок 9.

Так же, как и в испытаниях со стандартной конфигурацией, были проведены расчёты и усреднения масштабирования для тестов netserver, netperf и двусторонних тестов при масштабировании адаптеров Ethernet с 1 до 2 узлов, с 2 до 4 узлов и с 1 до 8 узлов. Результаты показаны в таблице 3.

В листинге 3 показана часть данных sar из тестов на масштабируемость netserver, когда netserver работал на всех четырёх адаптерах Ethernet на всех четырёх узлах. Данные приведены для размера сообщения 8 КБ и репрезентативны для всех тестов в этой среде. Указанные значения являются средними величинами на трёхминутном испытании. Данные показывают, что все прерывания отлично обрабатываются на тех процессорах, к которым они привязаны посредством аффинизации SMP IRQ.

                
CPU     %user     %nice   %system   %iowait    %steal    %idle
 0      0.05      0.00      0.05      0.00      0.00     99.90
 .
 4      2.22      0.00     49.21      0.00      0.00     48.57
 .
12      2.21      0.00     49.27      0.02      0.00     48.51
 .
20      2.25      0.00     51.59      0.00      0.00     46.17
 .
28      2.23      0.00     51.47      0.00      0.00     46.29
 .
36      2.86      0.00     56.06      0.00      0.00     41.08
 .
44      2.29      0.00     51.87      0.00      0.00     45.84
 .
52      2.69      0.00     55.28      0.00      0.00     42.02
 .
60      2.66      0.00     55.35      0.00      0.00     41.98
 .
 .      (unlisted values are 0 or near 0)
 .



        eth0     eth1     eth2     eth3     eth4     eth5     eth6     eth7
CPU     i177/s   i185/s   i193/s   i201/s   i209/s   i217/s   i225/s   i233/s

 4  15969.26     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 .
12      0.00 15959.40     0.00     0.00     0.00     0.00     0.00     0.00
 .
20      0.00     0.00 15721.47     0.00     0.00     0.00     0.00     0.00
 .
28      0.00     0.00     0.00 15693.93     0.00     0.00     0.00     0.00
 .
36      0.00     0.00     0.00     0.00 16000.84     0.00     0.00     0.00
 .
44      0.00     0.00     0.00     0.00     0.00 15981.13     0.00     0.00
 .
52      0.00     0.00     0.00     0.00     0.00     0.00 15855.95     0.00
 .
60      0.00     0.00     0.00     0.00     0.00     0.00     0.00 15700.12
 .
 .   (unlisted values are 0 or near 0)
 .
      

Аффинизация прерываний адаптеров Ethernet к процессорам соответствующих узлов (вместе с остановкой irqbalance) значительно сокращает загрузку процессора, повышая пропускную способность и одновременно улучшая масштабирование и пропускной способности, и загрузки процессора.

Привязка Ethernet SMP IRQ и numactl

Тесты на масштабируемость и методика проведения испытаний остались такими же, как и в стандартной конфигурации. Эта тестовая среда сочетает отличия последних двух описанных сред. Битовые маски SMP IRQ назначались так же, как и в предыдущем тесте, irqbalance был отключен, а numactl использовался для связывания netperf и (или) netserver на испытуемой системе с процессором и памятью соответствующего узла. Такая привязка numactl гарантирует, что экземпляры приложений будут запускаться на процессорах тех узлов, на которых установлены соответствующие адаптеры Ethernet, а также будут использовать память этих узлов.

Тесты netserver, netperf и двунаправленные тесты проводились так же, как и для стандартной конфигурации, сбор данных также проводился аналогичным образом. На рисунке 10 показана пропускная способность и загрузка процессора в тестах на масштабируемость netserver при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 10.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Тесты на масштабируемость netperf проводились так же, как и в предыдущей среде. На рисунке 11 показана пропускная способность и загрузка процессора в тестах на масштабируемость netperf при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы. Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Увеличить рисунок 11.

Таким же образом проводился двусторонний тест на масштабируемость . На рисунке 12 показаны пропускная способность и загрузка процессора в тестах при использовании адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы. Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Увеличить рисунок 12.

Расчёты масштабирования показаны в Таблице 4.

В листинге 4 показана часть данных sar из тестов на масштабируемость netserver, когда netserver работал на всех четырёх адаптерах Ethernet на всех четырёх узлах. Данные приведены для размера сообщения 8 КБ и репрезентативны для всех тестов в этой среде. Указанные значения являются средними величинами на трёхминутном испытании. Данные показывают, что все прерывания обрабатывались на тех процессорах, к которым они были привязаны посредством аффинизации SMP IRQ.

                
CPU     %user     %nice   %system   %iowait    %steal     %idle

 4      2.25      0.00     49.29      0.03      0.00     48.43
 .
12      2.61      0.00     51.82      0.00      0.00     45.58
 .
20      2.25      0.00     51.84      0.00      0.00     45.91
 .
28      2.85      0.00     57.43      0.00      0.00     39.72
 .
36      2.06      0.00     50.21      0.00      0.00     47.72
 .
44      2.04      0.00     53.34      0.00      0.00     44.62
 .
52      2.03      0.00     52.34      0.00      0.00     45.62
 .

60      2.28      0.00     54.28      0.00      0.00     43.44
 .
 .      (unlisted values are 0 or near 0)
 .



        eth0     eth1     eth2     eth3     eth4     eth5     eth6     eth7
CPU     i177/s   i185/s   i193/s   i201/s   i209/s   i217/s   i225/s   i233/s

 4   15962.89     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 .
12       0.00 15660.56     0.00     0.00     0.00     0.00     0.00     0.00
 .
20       0.00     0.00 15690.78     0.00     0.00     0.00     0.00     0.00
 .
28       0.00     0.00     0.00 15696.00     0.00     0.00     0.00     0.00
 .
36       0.00     0.00     0.00     0.00 15726.10     0.00     0.00     0.00
 .
44       0.00     0.00     0.00     0.00     0.00 15574.72     0.00     0.00
 .
52       0.00     0.00     0.00     0.00     0.00     0.00 15682.12     0.00
 .
60       0.00     0.00     0.00     0.00     0.00     0.00     0.00 15700.46
 .
 .   (unlisted values are 0 or near 0)
 .

Как было показано в предыдущем тесте, привязка обработки прерываний адаптеров Ethernet к процессорам соответствующих узлов (вместе с остановкой irqbalance) значительно сокращает загрузку процессора, повышая пропускную способность и масштабируемость. Далее, использование numactl для привязки сетевых приложений к процессорам и памяти узла, на котором установлен адаптер Ethernet, даёт небольшое преимущество в пропускной способности, загрузке процессора и масштабировании.

Объединение каналов Ethernet

Использование общего IP-адреса для части или всех адаптеров Ethernet в крупной многоузловой системе может быть удобно для системных администраторов и администрирования сети. В Linux имеется функция объединения каналов, которая, как было отмечено ранее, предоставляет множество методов объединения нескольких сетевых интерфейсов в единый логический интерфейс.

Драйвер для объединения каналов и вспомогательная утилита ifenslave к нему включаются в большинство дистрибутивов Linux. Драйвер имеет множество настроек и шесть политик объединения для балансировки трафика между объединенными интерфейсами. В число этих политик входят следующие:

• balance-rr (круговое обслуживание)
• adaptive-backup
• balance-xor
• broadcast
• 802.3ad
• balance-tlb (балансировка нагрузки по передаче)
• balance-alb (адаптивная балансировка нагрузки)

В этой статье рассматривается политика balance-alb , которая иногда называется "режим 6", поскольку она проста в настройке, не требует дополнительного конфигурирования оборудования и коммутаторов, а также выполняет балансировку нагрузки на объединенные интерфейсы как по отправке, так и по приему данных.

Чтобы установить объединение каналов на испытуемой системе:

1. Загрузите модуль объединения с адаптивной балансировкой нагрузки (режим 6) и значением задержки на включение (количество миллисекунд ожидания после восстановления канала для включения подчиненного канала): modprobe bonding mode=6 updelay=200.
2. Настройте основной интерфейс и включите его: ifconfig bond0 ip_address netmask netmask broadcast bcast .
3. Подключите все связываемые интерфейсы к основному: ifenslave bond0 eth0 eth1 eth2 eth3.

Чтобы продемонстрировать производительность и масштабируемость объединения, были проведены тесты на масштабируемость netserver с отключенным irqbalance и установкой назначений Ethernet SMP IRQ так же, как и в предыдущей тестовой среде. Используемые адаптеры Ethernet были объединены в один интерфейс с одним IP-адресом; каждый удаленный экземпляр netperf, работающий на нагрузочных машинах, отправлял сообщения на IP-адрес объединенного интерфейса.

Тесты на масштабируемость netserver и сбор данных проводились так же, как и в стандартной конфигурации, за исключением того, что на каждом узле использовался только один адаптер Ethernet. На рисунке 13 показана пропускная способность и загрузка процессора в тестах на масштабируемость netserver при использовании связанных первых адаптеров Ethernet, установленных на системных платах 1, 2 и 4 узлов испытуемой системы.

Увеличить рисунок 13.

Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Так же, как и в случае стандартных тестов, расчёты масштабирования приведены в таблице 5.

Приведенный фрагмент данных sar (листинг 5) из испытаний на масштабируемость netserver, когда netserver запускался на объединенном интерфейсе, представляет собой результат агрегирования данных для первых адаптеров Ethernet на системных платах каждого из четырёх узлов. Данные приведены при размере сообщения 8 КБ и репрезентативны для всех тестов в этой среде. Указанные значения являются средними величинами на трёхминутном испытании. Данные показывают, что все прерывания отлично обрабатывались на тех процессорах, к которым они привязаны.

                
CPU     %user     %nice   %system   %iowait    %steal    %idle

 4      2.02      0.00     72.32      0.00      0.00     25.67
 .
20      2.37      0.00     77.83      0.00      0.00     19.80
 .
36      1.72      0.00     74.71      0.00      0.00     23.57
 .
52      1.62      0.00     78.48      0.00      0.00     19.89
 .
 .      (unlisted values are 0 or near 0)
 .



        eth0     eth1     eth2     eth3     eth4     eth5     eth6     eth7
CPU     i177/s   i185/s   i193/s   i201/s   i209/s   i217/s   i225/s   i233/s

 4   16353.36     0.00     0.00     0.00     0.00     0.00     0.00     0.00
 .
20       0.00     0.00 15693.97     0.00     0.00     0.00     0.00     0.00
 .
36       0.00     0.00     0.00     0.00 15386.92     0.00     0.00     0.00 
 .
52       0.00     0.00     0.00     0.00     0.00     0.00 15570.74     0.00
 .
 .   (unlisted values are 0 or near 0)
 .

На рисунке 14 показано сравнение испытаний на масштабируемость netserver при использовании 2 адаптеров (1 на каждом из первых 2 узлов) и 4 адаптеров (1 на каждом из 4 узлов) с объединением и без него. Показанная пропускная способность является суммой пропускных способностей всех использованных адаптеров Ethernet в каждом тесте; показанная загрузка процессора является средней по системе за время выполнения каждого теста.

Увеличить рисунок 14.

Несмотря на наличие некоторых издержек, связанных с объединением Ethernet, результаты тестов показывают, что сетевые ресурсы объединенных интерфейсов Ethernet хорошо масштабируются и работают по сравнению с организацией сети по несвязанным интерфейсам Ethernet. Административные преимущества и возможность упрощения сетевых приложений, открываемые объединением, могут перевесить издержки производительности.

В начало

Заключение

Улучшения irqbalance В результате проведенного исследования и на основании выводов, изложенных в этой статье, были предложены и реализованы улучшения irqbalance, делающие процесс аффинизации на многоузловых системах более автоматизированным. Эти улучшения позволяют irqbalance использовать дополнительную информацию, экспортируемую из BIOS многоузловых систем, для принятия лучших решений о назначении IRQ в таких системах. Эти улучшения должны появиться в будущих дистрибутивах Linux.

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

Чтобы обеспечить лучшую масштабируемость и производительность сети, сделайте так, чтобы прерывания адаптеров Ethernet обрабатывались процессорами локальных для адаптеров узлов. Вы можете привязать обработку прерываний к нужным процессорам (аффинизация), остановив предварительно irqbalance, удалив его из сценариев инициализации, включив соответствующим образом аффинизацию SMP IRQ и поместив её конфигурацию в сценарии инициализации. Аффинизация без предварительной остановки irqbalance не имеет смысла. После успешной настройки привязки SMP IRQ по возможности привяжите сетевые приложения к процессорам локальных узлов, на которых находятся используемые адаптеры Ethernet.

Объединение Ethernet -- это очень полезная функция Linux, которая предоставляет множество способов объединения сетевых интерфейсов в единый логический интерфейс. Относительно небольшие издержки легко компенсируются административными преимуществами организации сети.

Поделиться этой статьей digg.com del.icio.us slashdot.org

Приведенные результаты тестов показывают, что общая масштабируемость сети под Linux при правильной настройке систем IBM eServer xSeries x460 может находиться на хорошем уровне даже если используемые сетевые адаптеры находятся на других узлах системы. Средняя масштабируемость при различных размерах отправляемых сообщений составляла до 1,999 при переходе от использования 2 адаптеров Ethernet на 1 узле к 4 адаптерам на 2 узлах до 1,945 при переходе от использования 4 адаптеров Ethernet на двух узлах к 8 адаптерам на 4 узлах. Соответствующий средний коэффициент масштабируемости загрузки процессора составлял 2,076 при переходе от использования 2 адаптеров Ethernet на 1 узле к 4 адаптерам на 2 узлах и до 2,081 при переходе от использования 4 адаптеров Ethernet на двух узлах к 8 адаптерам на 4 узлах.

Ресурсы

• Оригинал статьи "Networking scalability on high-performance servers (EN)".
  
  
• Серия "Создание высокопроизводительных кластеров Linux (EN)" на developerWorks посвящена применению Linux-систем для высокопроизводительных вычислений.
  
  
• Серия "Установка большого Linux-кластера (EN)" на developerWorks поможет вам найти ответы на многие вопросы по многоузловым системам Linux.
  
  
• Настройка серверов IBM System x на производительность (EN)" (Руководства IBM Redbooks, февраль 2007) - показывает, как максимально улучшить производительность серверных бизнес-приложений, работающих на оборудовании IBM System x под управлением операционных систем Windows, Linux или ESX Server.
  
  
• На домашней странице Netperf можно узнать о netperf и производительности систем, протестированных с помощью netperf.
  
  
• Драйвер объединения Linux позволяет объединить несколько сетевых интерфейсов в один логический интерфейс.
  
  
• В разделе Linux сайта developerWorks можно найти дополнительные ресурсы для разработчиков Linux, а также самые популярные среди наших читателей статьи и руководства.
  
  
• Посмотрите все советы по Linux и руководства Linux на сайте developerWorks.
  
  
• Следите на последними новостями на портале Web-трансляций и технических мероприятий developerWorks.
  
  

• Перейдите на страницу IBM System x, где можно найти подробную информацию о продукте, технические данные, статьи и многое другое о серверах x86 для Windows и Linux.
  
  
• Утилиты sysstat - это инструментарий контроля производительности для Linux, включающий такие инструменты, как sar, sadf, mpstat, iostat, pidstat и sa.
  
  
• irqbalance - это демон Linux, который распределяет прерывания по нескольким процессорам и ядрам вашей вычислительной системы. irqbalance пытается найти баланс между экономией мощности и оптимальной производительностью.
  
  
• Закажите SEK для Linux - набор из двух DVD, содержащий новейшие ознакомительные версии программного обеспечения IBM для Linux от DB2®, Lotus®, Rational®, Tivoli® и WebSphere ®.
  
  
• Используйте в своем следующем проекте разработки для Linux ознакомительные версии программного обеспечения IBM, которые можно скачать непосредственно с developerWorks.
  
  

• Примите участие в обсуждении материала на форуме.
  
  
• Присоединяйтесь к сообществу developerWorks и знакомьтесь с блогами, форумами, подкастами и материалами для совместного обсуждения на обновленном пространстве нашего портала developerWorks.

Об авторе

		Барри Арндт (Barry Arndt) -- старший инженер-разработчик и аналитик производительности в IBM в Остине, штат Техас, США. С 2000 года он работает над разработкой и повышением производительности Linux в центре Linux-технологий корпорации IBM (IBM Linux Technology Center). До этого Барри был разработчиком стека сетевых протоколов OS/2. Он поступил на работу в IBM в 1989 году, после того, как получил степень в области математики и вычислительной техники в университете Пардью.

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало