receive side scaling что это

Receive Side Scaling — что это?

Receive Side Scaling — данная функция предназначена для равномерного распределения входного трафика по обработки пакетов между ядрами процессора, тем самым оптимизируя производительность.

Описание от Intel: при включении масштабирования на стороне приема (RSS), вся обработка данных приема для конкретного TCP-соединения совместно используется несколькими процессорами или ядрами. Без RSS вся обработка выполняется одним процессором (CPU) или одним ядром, это приводит к неэффективному использованию системного кэша.

Название опции на русском — Получение бокового масштабирования.

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

Положительный эффект от опции может быть при условии что драйвер корректно работает. Были случаи что после включения — начинались глюки, тормоза.

Эта опция встречается в сетевых адаптерах Intel, NVIDIA.

Иногда включенная эта опция приводит к медленной работе сети (особенно при использовании серверной ОС), поэтому в некоторых случаях ее стоит отключить:

Также отключить можно через реестр:

Надеюсь данная информация оказалась полезной. Успехов.

Источник

Общие сведения о масштабировании на стороне приема

Масштабирование на стороне приема (RSS) — это технология сетевого драйвера, которая позволяет эффективно распределять обработку приема в сети между несколькими процессорами в многопроцессорных системах.

Поскольку процессоры с технологией Hyper-Threading на одном и том же ядре процессора используют один и тот же механизм выполнения, этот результат не совпадает с наличием нескольких основных процессоров. По этой причине RSS не использует процессоры с технологией Hyper-Threading.

Чтобы эффективно обрабатывать полученные данные, функция «получить прерывание» драйвера минипорта планирует отложенный вызов процедуры (DPC). Без RSS обычная DPC обозначает все полученные данные в вызове DPC. Таким образом, вся обработка приема, связанная с прерыванием, выполняется на ЦП, где происходит прерывание приема. Общие сведения об обработке данных, отличных от RSS, см. в разделе Обработка приема, отличной от RSS.

При использовании RSS драйвер сетевого адаптера и драйвера минипорта предоставляет возможность запланировать получение DPC на других процессорах. Кроме того, структура RSS гарантирует, что обработка, связанная с данным соединением, останется в назначенном ЦП. Сетевая карта реализует хэш-функцию, а полученное хэш-значение предоставляет средства для выбора ЦП.

На следующем рисунке показан механизм RSS для определения ЦП.

Сетевая карта использует функцию хэширования для вычисления хэш-значения по определенной области (тип хэша) в полученных сетевых данных. Определенная область может быть не непрерывной.

Для индексации таблицы косвенных обращений используются несколько наиболее значимых битов (Лсбс) хэш-значения. Значения в таблице косвенных обращений используются для назначения полученных данных ЦП.

Дополнительные сведения об указании таблиц косвенных обращений, типов хэширования и функциях хэширования см. в разделе Конфигурация RSS.

Благодаря поддержке сигнала прерывания (MSI) сетевая карта может также прерывать связанный ЦП. Дополнительные сведения о поддержке NDIS для MSI см. в разделе NDIS MSI-X.

Аппаратная поддержка RSS

На следующем рисунке показаны уровни аппаратной поддержки RSS.

Существует три возможных уровня поддержки оборудования для RSS:

Вычисление хэша с одной очередью
Сетевой адаптер вычисляет хэш-значение, и драйвер минипорта назначает полученные пакеты очередям, связанным с процессорами. Дополнительные сведения см. в разделе RSS с одной очередью получения оборудования.

Вычисление хэша с несколькими очередями получения
Сетевой адаптер назначает полученные буферы данных очередям, связанным с процессорами. Дополнительные сведения см. в разделе RSS с очередью оборудования.

Сообщения с сигнальными прерываниями (MSI)
Сетевая карта прерывает работу процессора, который должен обслуживать полученные пакеты. Дополнительные сведения см. в разделе RSS с сигнальными прерываниями.

Сетевая карта всегда передается в 32-разрядном хэш-значении.

Улучшение производительности системы RSS

RSS может улучшить производительность сетевой системы, уменьшая:

Задержка обработки за счет распределения обработки приема от сетевых карт между несколькими процессорами.

Это помогает гарантировать, что ЦП не будет сильно загружен, пока другой ЦП бездействует.

Затраты на блокировку путем увеличения вероятности того, что программные алгоритмы, которые совместно используют данные, выполняются на одном и том же ЦП.

Накладные расходы на спин-блокировки происходят, например, когда функция, выполняемая в CPU0, обладает спин-блокировкой данных, к которой должна иметь доступ функция, работающая в CPU1. CPU1 вращается (ожидает), пока CPU0 не освободит блокировку.

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

Такая перезагрузка происходит, например, когда функция, выполняющая и обращающаяся к общим данным в CPU0, выполняется в CPU1 в последующем прерывании.

Для достижения этих улучшений производительности в безопасной среде RSS предоставляет следующие механизмы:

RSS распределяет обработку назначением Receive с заданной сетевой карты в DPC на несколько процессоров.

Обработка в порядке

RSS сохраняет порядок доставки полученных пакетов данных. Для каждого сетевого подключения процессы RSS принимают указания по связанному ЦП. Дополнительные сведения об обработке приема RSS см. в разделе Указание RSS-приема данных.

Динамическая балансировка нагрузки

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

Масштабирование на стороне отправки

RSS позволяет стекам драйверов обрабатывать данные отправки и приема для заданного соединения в одном ЦП. Как правило, драйвер с независимым доступом (например, TCP) отправляет часть блока данных и ожидает подтверждения перед отправкой баланса данных. Затем подтверждение активирует последующие запросы на отправку. Таблица косвенного обращения RSS определяет конкретный ЦП для обработки приема данных. По умолчанию обработка отправки выполняется на том же ЦП, если он запускается подтверждением получения. Драйвер также может указывать ЦП (например, если используется таймер).

RSS содержит подпись, которая обеспечивает дополнительную безопасность. Эта подпись защищает систему от вредоносных удаленных узлов, которые могут попытаться принудительно перевести систему в несбалансированное состояние.

RSS с поддержкой MSI-X запускает процедуру обработки прерываний (ISR) на том же ЦП, который позже выполняет DPC. Это сокращает затраты на блокировку и перезагрузку кэшей.

Источник

Большие потоки трафика и управление прерываниями в Windows

Мне очень понравился топик про распределение нагрузки от прерываний сетевого адаптера по процессорам, поэтому я решил описать как это делается в Windows.

Disclaimer: судя по некоторым комментариям в предыдущих постах, мне стоит повторить то, с чего я начал первый пост: я не даю (и не могу давать) общеприменимых рецептов. Особенно это касается производительности, где мельчайшая неучтенная деталь может катастрофически повлиять на результат. Вернее рекомендацию то я даю: ТЕСТИРОВАНИЕ И АНАЛИЗ. Смысл моей писанины в том, чтобы дать людям как можно больше информации для анализа, ведь, чем больше понимаешь в том, как что либо работает, тем легче находить пути устранения боттлнеков.

Итак, масштабируемость пропускной способности сети. Потребуется Windows Server 2003 SP2+. Сетевая карта, поддерживающая Receive Side Scaling (можно с достаточной долей уверенности сказать, что подойдет любая серверная сетевая карта, выпущенная в последние 5 лет или любая вообще 1Gb+ NIC, хотя частенько можно увидеть RSS и на 100Mb). Устанавливаем Windows Server и драйвера на карту…

ВСЕ. Настройка завершена. RSS по умолчанию включен во всех версиях Windows, в которых он поддерживается.

Тестирование

Возьмем не особо новый Dell-овый сервер с двумя четырехядерными ксеонами:

На борту две двухпортовые 1Gb сетевые карты и одна 10Gb, но я не нашел 10Gb свитча, так что завести не удалось — ну да ладно:

Что интересно в этих картах, так это то, что несмотря на поддержку RSS в 8 очередей, они не поддерживают ни MSI-X ни даже MSI. Более того, из четырех доступных линий pin-based прерываний на каждый сетевой порт отведена только одна (соответственно никакими способами заставить прерывания приходить на разные процессоры уже нельзя — это аппаратное ограничение данной конфигурации). 10 гигабитка зарегистрировала на себя то ли 32 то ли 64 (на глаз) вектора прерываний, но ее использовать — не судьба. Сможет ли индусская поделка для запуска игр справиться с задачей?

На всякий случай проверяем RSS (хотя если его не будет — будет заметно и так):

Для начала выключим RSS (включал обратно я уже после тестирования, но том же окне)

и запустим нагрузочный тест:
Полностью загружены два ядра, все остальные простаивают

Сеть загружена на треть:

50% одного процессора забито обработакой прерываний, еще 20% того же процессора — обработка DPC. Остальное — tcpip стек и приложение, которое отдает трафик.

Включаем RSS (скриншот выше). Процессор:

Сеть:

Треть одного процессора забита прерываниями, но DPC отлично распараллелены.

В общем, на данной конфигурации можно было бы отдавать порядка 3 гигабит (с одной сетевой карты) и только тогда мы бы встретили бутылочное горлышко.

На всякий случай, скажу, что у RSS есть менее известный родственник — Send Side Scaling. Если перед посылкой списка буферов выставить значение хеша, то прерывание после завершения посылки будет доставлено в соответствии с установленными indirection table-ами.

Вот здесь можно почитать про RSS, а здесь есть неплохая презентация в картинках поясняющая работу RSS. Если интересно, могу попробовать своими словами описать механизмы работы RSS, но как по мне — лучше читать первоисточники.

TCP Offload Engine

Если нечто подобное RSS в Linux вот-вот появится (не нашел никаких упоминаний о поддержке нормального аппаратного RSS в Linux: кто знает — дайте ссылку — проапдейчу пост). То с TOE в Linux все официально сложно. Патч от Chelsio (один из производителей high-end сетевых карт), реализующий поддержку TOE, был отклонен, а вместо этого начались какие то совершенно идиотские отмазки (при прочтении стоит иметь в виду, что BSD и Windows имеют нормальную поддержку TOE уже много лет).

Итак, что же это такое? TOE — это полная реализация TCPIP на аппаратном уровне: с подтверждением доставки, ретрансмитами при ошибках, контролем окна и пр.: сетевая карта по DMA прямо из памяти берет данные, режет на пакеты, присоединяет хедеры, а рапортует (при помощи прерываний) только в самых крайних случаях.

По умолчанию TOE стоит в automatic режиме. Смотреть Chimney Offload State:

Скриншот снимался во время активного тестирования, но в статистике видно, что ни одного «выгруженного» в сетевую карту соединения нет (о причинах позже). Включем принудительно (и через некоторое время запрашиваем статистику):

А вот и причина: в данную сетевую карту можно выгрузить только 1024 соединения (но реально система смогла выгрузить 1022). Довольно дорогой ресурс, чтоб можно было выгружать все подряд. Система эвристически пытается обнаруживать соединения (get/put больших файлов по http, пересылка файлового контента на файл-серверах и т.п.), которые проживут долго и выгружает в первую очередь их.

Но все же глянем, что получилось. Процессор разгрузился втрое:

Очень сильно уменьшилось количество (и время проводимое в) как ISR так и DPC:

Источник

Настройка производительности сетевых адаптеров

область применения: Windows server 2022, Windows server 2019, Windows Server 2016, Azure Stack хЦи, версии 21H2 и 20H2

используйте сведения в этом разделе для настройки сетевых адаптеров производительности для компьютеров под управлением Windows Server 2016 и более поздних версий. Если сетевые адаптеры предоставляют параметры настройки, эти параметры можно использовать для оптимизации пропускной способности сети и использования ресурсов.

Правильные параметры настройки для сетевых адаптеров зависят от следующих переменных.

В следующих разделах описывается ряд параметров настройки производительности.

Включение функций разгрузки

Включение функций разгрузки на сетевом адаптере обычно имеет положительный эффект. Однако сетевой адаптер может оказаться недостаточно мощным для обработки возможностей разгрузки с высокой пропускной способностью.

Не используйте разгрузку задач IPSec функции разгрузки или разгрузку TCP Chimney. эти технологии являются устаревшими в Windows Server 2016 и могут негативно сказаться на производительности сервера и сети. Кроме того, эти технологии могут не поддерживаться корпорацией Майкрософт в будущем.

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

Для некоторых сетевых адаптеров требуется включить разгрузку компонентов независимо для путей отправки и получения.

Включение масштабирования на стороне приема (RSS) для веб-серверов

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

Избегайте использования сетевых адаптеров, отличных от RSS, и сетевых адаптеров, поддерживающих RSS, на одном сервере. Из-за логики распределения нагрузки в RSS и протоколе HTTP, производительность может быть значительно снижена, если сетевой адаптер, не поддерживающий RSS, принимает веб-трафик на сервере с одним или несколькими сетевыми адаптерами, поддерживающими RSS. В этом случае необходимо использовать сетевые адаптеры, поддерживающие RSS, или отключить RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Чтобы определить, поддерживает ли сетевой адаптер RSS, можно просмотреть сведения RSS на вкладке Дополнительные свойства в свойствах сетевого адаптера.

Профили RSS и очереди RSS

стандартный профиль RSS по умолчанию — нумастатик, который отличается от используемого по умолчанию предыдущих версий Windows. Прежде чем приступить к использованию профилей RSS, ознакомьтесь с доступными профилями, чтобы понять, когда они полезны и как они применяются к сетевой среде и оборудованию.

Например, если открыть диспетчер задач и проверить логические процессоры на сервере и они будут недостаточно загружены для приема трафика, можно попробовать увеличить число очередей RSS по умолчанию, равное двум, до максимума, поддерживаемого сетевым адаптером. В используемом сетевом адаптере могут быть параметры для изменения числа очередей RSS в драйвере.

Увеличение ресурсов сетевого адаптера

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

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

Если сетевой адаптер не предоставляет настройки ресурсов вручную, он динамически настраивает ресурсы, или для ресурсов задано фиксированное значение, которое нельзя изменить.

Включение контроля прерываний

Для управления прерываниями прерываний некоторые сетевые адаптеры предоставляют различные уровни управления прерываниями, различные параметры объединения буфера (иногда отдельно для буферов отправки и получения) или и то, и другое.

Следует рассмотреть возможность контроля прерываний для рабочих нагрузок, привязанных к ЦП. При использовании управления прерываниями учитывайте компромисс между экономией ЦП узла и задержкой, а также увеличением экономии ресурсов узла из-за большего количества прерываний и снижения задержки. Если сетевой адаптер не выполняет контроль прерываний, но он предоставляет объединение буферов, можно повысить производительность, увеличив число Объединенных буферов, чтобы освободить больше буферов на отправку или получение.

Настройка производительности для обработки пакетов с низкой задержкой

Многие сетевые адаптеры позволяют настраивать параметры для оптимизации системной задержки. Задержка — это время между обработкой входящего пакета сетевым драйвером и отправкой этого пакета обратно. Обычно это время измеряется в микросекундах. Для сравнения время передачи пакетов на длинные дистанции обычно измеряется в миллисекундах (это на порядок дольше). Эта настройка не сокращает время прохождения пакета.

Ниже приведены некоторые советы по настройке производительности для загруженных сетей, в которых на счету каждая микросекунда.

Установите в операционной системе профиль управления электропитанием Высокая производительность.

Этот параметр не работает должным образом, если BIOS системы имеет значение отключить управление питанием в операционной системе.

Включить статические разгрузки. Например, включите контрольные суммы UDP, контрольные суммы TCP и отправку параметров большой разгрузки (LSO).

Если трафик проходит через несколько потоков, например при получении многоуровневого трафика многоадресной рассылки, включите RSS.

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

Обрабатывайте прерывания сетевого адаптера и DPC на основном процессоре, который совместно использует процессорный кэш с ядром, которое используется программой (пользовательским потоком), обрабатывающей пакет. Для передачи процесса конкретным логическим процессорам можно использовать настройку фиксации ЦП вместе с настройкой RSS. Использование одного ядра для прерываний, DPC и пользовательского потока ведет к снижению производительности из-за увеличения нагрузки, поскольку ISR, DPC и поток будут конкурировать за ядро.

Прерывания управления системой

Многие аппаратные системы используют прерывания управления системой (SMI) для различных функций обслуживания, таких как сообщения об ошибках с кодом коррекции ошибок (ECC), поддержка устаревшей совместимости с USB, управление вентилятором и управление параметрами питания, управляемой BIOS.

SMI — это прерывание с наивысшим приоритетом в системе и помещает ЦП в режим управления. Этот режим загружает все остальные действия, в то время как SMI запускает подпрограммы службы прерываний, обычно содержащиеся в BIOS.

К сожалению, такое поведение может привести к скачкам задержки 100 микросекунд или более.

Когда необходимо обеспечить минимальную задержку, следует запросить у поставщика оборудования версию BIOS, в которой прерывания SMI имеют наименьший возможный приоритет. Эти версии BIOS часто называются «BIOS с низкой задержкой» или «SMI Free BIOS». В некоторых случаях аппаратная платформа не может полностью исключить активность SMI, так как она используется для управления важными функциями (например, вентиляторами).

Операционная система не может управлять SMIs, так как логический процессор работает в специальном режиме обслуживания, что предотвращает вмешательство пользователя операционной системы.

Настройка производительности TCP

Для настройки производительности TCP можно использовать следующие элементы.

Автоматическая настройка окна приема TCP

в более ранних версиях Windows сетевой стек Windows использовал окно приема фиксированного размера (65 535 байт), которое ограничивает общую возможную пропускную способность для подключений. Общая пропускная способность подключений TCP может ограничивать сценарии использования сети. Автоматическая настройка окна приема TCP позволяет этим сценариям полностью использовать сеть.

Для окна приема TCP, имеющего определенный размер, можно использовать следующее уравнение для вычисления общей пропускной способности отдельного соединения.

Общая пропускная способность в байтах Размер окна приема TCP в байтах * (1/ Задержка подключения в секундах)

Например, для соединения с задержкой 10 мс общая пропускная способность составляет только 51 Мбит/с. Это значение целесообразно для большой корпоративной сетевой инфраструктуры. Однако с помощью автонастройки для настройки окна приема подключение может обеспечить полную скорость линии для подключения 1 Гбит/с.

Некоторые приложения определяют размер окна приема TCP. Если приложение не определяет размер окна приема, скорость связи определяется следующим образом:

Например, на компьютере с установленным сетевым адаптером с 1 Гбит/с размер окна должен быть 64 КБ.

Эта функция также обеспечивает полное использование других функций для повышения производительности сети. Эти функции включают остальные параметры TCP, определенные в RFC 1323. используя эти функции, компьютеры на базе Windows могут согласовать размеры окна приема TCP, которые меньше, но масштабируются по определенному значению в зависимости от конфигурации. Такое поведение упрощает обработку размеров для сетевых устройств.

Может возникнуть проблема, при которой сетевое устройство не соответствует параметру TCP Window Scale, как определено в RFC 1323 и, следовательно, не поддерживает коэффициент масштабирования. в таких случаях обратитесь к этой статье KB 934430, если вы пытаетесь использовать Windows Vista за устройством брандмауэра или обратитесь в службу поддержки для поставщика сетевых устройств.

Проверка и настройка уровня автонастройки окна приема TCP

для просмотра или изменения уровня автонастройки окна приема TCP можно использовать команды netsh или командлеты Windows PowerShell.

в отличие от версий Windows, которые предварительно устарели Windows 10 или Windows Server 2019, вы больше не можете использовать реестр для настройки размера окна приема TCP. Дополнительные сведения об устаревших параметрах TCPсм. здесь.

Подробные сведения о доступных уровнях автонастройки см. в разделе уровни автонастройки.

Использование команды Netsh для просмотра или изменения уровня автонастройки

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

Выходные данные этой команды должны выглядеть следующим образом:

Чтобы изменить этот параметр, выполните в командной строке следующую команду:

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Использование PowerShell для просмотра или изменения уровня автонастройки

Чтобы проверить текущие параметры, откройте окно PowerShell и выполните следующий командлет.

Выходные данные этого командлета должны выглядеть следующим образом.

Чтобы изменить этот параметр, выполните следующий командлет в командной строке PowerShell.

В предыдущей команде представляет новое значение для уровня автоматической настройки.

Дополнительные сведения об этих командлетах см. в следующих статьях:

Уровни автонастройки

Можно настроить автоматическую настройку окна приема на любой из пяти уровней. Уровень по умолчанию — Обычная. В следующей таблице описаны уровни.

Если для записи сетевых пакетов используется приложение, приложение должно сообщить данные, аналогичные приведенным ниже, для различных параметров автонастройки окна.

Уровень автонастройки: нормальный (состояние по умолчанию)

Уровень автонастройки: отключен

Уровень автонастройки: ограниченный

Уровень автонастройки: очень ограниченный

Уровень автонастройки: экспериментальный

Устаревшие параметры TCP

следующие параметры реестра из Windows Server 2003 больше не поддерживаются и не учитываются в более поздних версиях.

Все эти параметры были расположены в следующем подразделе реестра:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

Платформа фильтрации Windows

Windows в Vista и Windows Server 2008 появилась платформа фильтрации Windows (WFP). WFP предоставляет интерфейсы API независимым поставщикам программного обеспечения (ISV) для создания фильтров обработки пакетов. Например, для брандмауэров и антивирусного ПО.

Плохо написанный фильтр WFP может значительно снизить производительность сети сервера. дополнительные сведения см. в разделе перенос Packet-Processing драйверов и приложений в WFP в Windows Центр разработки.

Ссылки на все разделы данного руководства см. в разделе Настройка производительности сетевой подсистемы.

Источник