Receive side scaling что это
Receive Side Scaling — что это?
Receive Side Scaling — данная функция предназначена для равномерного распределения входного трафика по обработки пакетов между ядрами процессора, тем самым оптимизируя производительность.
Описание от Intel: при включении масштабирования на стороне приема (RSS), вся обработка данных приема для конкретного TCP-соединения совместно используется несколькими процессорами или ядрами. Без RSS вся обработка выполняется одним процессором (CPU) или одним ядром, это приводит к неэффективному использованию системного кэша.
Название опции на русском — Получение бокового масштабирования.
При включении — пакеты распределяются по потокам, каждый поток может обрабатывать отдельный процессор. Результат — задействуются все ядра процессора, что положительно влияет на производительности сети, пинге. Когда функция отключена — поступающий трафик обрабатывается одним ядром, если оно имеет высокую частоту — хорошо, однако если низкую — производительность сети может снизиться.
Положительный эффект от опции может быть при условии что драйвер корректно работает. Были случаи что после включения — начинались глюки, тормоза.
Эта опция встречается в сетевых адаптерах Intel, NVIDIA.
Иногда включенная эта опция приводит к медленной работе сети (особенно при использовании серверной ОС), поэтому в некоторых случаях ее стоит отключить:
Также отключить можно через реестр:
Надеюсь данная информация оказалась полезной. Успехов.
Масштабирование на стороне приема для сетевых адаптеров Intel®
Тип материала Установка и настройка
Идентификатор статьи 000006703
Последняя редакция 31.01.2020
При включении масштабирования на стороне приема (RSS) все приемы обработки данных для конкретного TCP-подключения используются несколькими процессорами или ядрами процессора. Без RSS все процессы обработки данных выполняются одним процессором, что приводит к неэффективному использованию кэша системы.
Конфигурация RSS-канала
Поддержка RSS доступна на вкладке «Дополнительно» окна свойств адаптера. Если ваш адаптер или операционная система не поддерживают RSS-канал, Настройка RSS не отображается.
Сотрудничество
Известные проблемы
В ОС Windows Server 2012 * Настройка RSS для ближайших процессоров может привести к сбоям при передаче и получении
Неисправное подключение и возможна нестабильность системы
Если в вашей системе установлены сетевые устройства, отличные от Intel, которые поддерживают масштабирование на стороне заказчика, ключевое слово рссбасекпу могло быть изменено со значения по умолчанию, равного 0x0, для указания логического процессора. Если это ключевое слово было изменено, устройства, основанные на контроллерах Intel® 82598 или 82599 10 Gigabit Ethernet, могут не передавать трафик. Попытка внести изменения в драйвер в этом состоянии может привести к нестабильной работе системы. Присвойте параметру Рссбасекпу значение 0x0 или значение, соответствующее физическому процессору, и перезагрузите систему, чтобы устранить проблему.
Значение масштабирования «получение стороны» пусто
Изменение параметров масштабирования на стороне приема для адаптера в команде может привести к тому, что значение этого параметра будет оставлено пустым при следующей проверке. Кроме того, она может быть оставлена пустой для других адаптеров в команде. Возможно, адаптер не будет связан с командой в такой ситуации. Отключение и включение команды позволили решить проблему.
Использование ЦП выше ожидаемого
Установка для очередей RSS большего размера, чем 4, рекомендуется только для крупных веб-серверов с несколькими процессорами. Значения выше 4 могут привести к увеличению использования ЦП до неприемлемых уровней и другим негативным последствиям для производительности системы.
Повышение пропускной способности сетевых интерфейсов для SQL Server с помощью настройки параметров RSS
Недавно автор работал с партнёром над тестированием возможностей масштабирования сетевой нагрузки SQL Server. В тестах использовался сервер DL980 с 8 процессорными сокетами, которые представляли системе 80 физических ядер, и управлялось всё это операционной системой Windows 2008 R2 sp1. В распоряжении SQL Server было 4 сетевых карты производительностью 1Gbps, они поддерживали сетевой трафик между SQL Server и серверами приложений. К удивлению автора, максимальная загрузка во время теста наблюдалась только на 2-х из 80-ти процессорных ядер, и практически вся эта нагрузка приходилась на привилегированный режим работы процессоров (privileged/DPC % time). Известно, что Windows 2008 R2 по умолчанию использует до 4-х процессорных ядер для управляющих модулей, относящихся к RSS (см. упомянутую выше статью). Почему же в данном случае использовалось только 2 процессора? Стоит отметить, что то время, которое процессоры работали в привилегированном режиме, могло относиться к деятельности драйверов устройств, таких как сетевое оборудование и драйверы системы хранения данных. Воспользовавшись входящим в комплект Windows SDK инструментом XPerf, можно проследить работу подобных устройств на уровне драйверов и выявить основного потребителя привилегированного режима процессоров. В данном случае, большая часть этого режима использовалась для обслуживания драйвера сетевых устройств NDIS.sys.
Подозревая, что описанное выше поведение могло проявиться в Windows ошибочно, автор явным образом задал значение для ключа реестра HLKM\System\CurrentControlSet\Services\Ndis\Parameters, установив параметру MaxNumRssCpus значение 8 (подробности об этом ключе можно найти в упомянутом выше статье), в надежде, что эта установка позволит привлечь дополнительные процессоры, для обслуживания прерываний, связанных с передаваемыми по сети пакетами. Но, эта настройка никак не повлияла на число используемых процессоров. Автор обратился за консультациями к коллегам в Windows Networking Team, с просьбой помочь решить эту проблему. Пока ответ ещё не был получен, была предпринята попытка подключить серверы приложений используя все 4 сетевые платы (серверы приложений были поделены равномерно по количеству сетевых карт, каждая группа серверов подключается только к одному IP-адресу). К всеобщей радости, большой процент привилегированной нагрузки теперь наблюдался на 8ми ядрах.
В итоге, в качестве решения проблемы был избран вариант с масштабированием сетевой нагрузки, когда использовались 4 сетевые платы со своими IP адресами. Это позволило получить нужную пропускную способность сетевых интерфейсов, и обеспечить обслуживание RSS таким числом процессоров, которое позволило эффективно обслужить большой сетевой трафик. Конечно, можно использовать более производительные сетевые платы 10Gbps, но при этом следует обязательно задавать правильные значения для «RSS rings».
В качестве резюме можно выделить два основных момента в настройке RSS для обслуживания нагрузки SQL Server с большим сетевым трафиком:
Настройте в Windows максимальное число задействованных для RSS процессоров («starting RSS CPU») руководствуясь рекомендациями в статье: Receive-Side Scaling Enhancements in Windows Server 2008
Для каждой используемой сетевой платы задайте значения «RSS Rings» («RSS Queues») таким образом, чтобы сумма этих значений для всех сетевых плат соответствовала значению MaxNumRssCpu в реестре Windows. Учтите, что максимально возможное значение у разных производителей плат может отличаться. Чтобы обеспечить необходимую производительность обслуживания большого трафика по сети, возможно, придётся обновить драйвера/firmware или установить дополнительные сетевые платы.
Увеличение пропускной способности сетевой платы с помощью настройки RSS
По материалам статьи: Кун Ченг (Kun Cheng) Maximizing SQL Server Throughput with RSS Tuning
Функциональность Receive-Side Scaling (RSS) впервые появилась в Windows 2003. Это нововведение было призвано повысить возможности масштабируемости операционной системы Windows, и этим предоставить новые возможности по обслуживанию большого сетевого трафика. Такой трафик характерен для систем, где SQL Server обслуживает OLTP нагрузку. Подробное описание того, какие усовершенствования RSS получила операционная система Windows 2008, можно узнать из отчёта – Receive-Side Scaling Enhancements in Windows Server 2008 и в блоге – Scaling Heavy Network Traffic with Windows.
Недавно автор работал с партнёром над тестированием возможностей масштабирования сетевой нагрузки SQL Server. В тестах использовался сервер DL980 с 8 процессорными сокетами, которые представляли системе 80 физических ядер, и управлялось всё это операционной системой Windows 2008 R2 sp1. В распоряжении SQL Server было 4 сетевых карты производительностью 1Gbps, они поддерживали сетевой трафик между SQL Server и серверами приложений. К удивлению автора, максимальная загрузка во время теста наблюдалась только на 2-х из 80-ти процессорных ядер, и практически вся эта нагрузка приходилась на привилегированный режим работы процессоров (privileged/DPC % time). Известно, что Windows 2008 R2 по умолчанию использует до 4-х процессорных ядер для управляющих модулей, относящихся к RSS (см. упомянутую выше статью). Почему же в данном случае использовалось только 2 процессора? Стоит отметить, что то время, которое процессоры работали в привилегированном режиме, могло относиться к деятельности драйверов устройств, таких как сетевое оборудование и драйверы системы хранения данных. Воспользовавшись входящим в комплект Windows SDK инструментом XPerf, можно проследить работу подобных устройств на уровне драйверов и выявить основного потребителя привилегированного режима процессоров. В данном случае, большая часть этого режима использовалась для обслуживания драйвера сетевых устройств NDIS.sys.
Подозревая, что описанное выше поведение могло проявиться в Windows ошибочно, автор явным образом задал значение для ключа реестра HLKM\System\CurrentControlSet\Services\Ndis\Parameters, установив параметру MaxNumRssCpus значение 8 (подробности об этом ключе можно найти в упомянутом выше статье), в надежде, что эта установка позволит привлечь дополнительные процессоры, для обслуживания прерываний, связанных с передаваемыми по сети пакетами. Но, эта настройка никак не повлияла на число используемых процессоров. Автор обратился за консультациями к коллегам в Windows Networking Team, с просьбой помочь решить эту проблему. Пока ответ ещё не был получен, была предпринята попытка подключить серверы приложений используя все 4 сетевые платы (серверы приложений были поделены равномерно по количеству сетевых карт, каждая группа серверов подключается только к одному IP-адресу). К всеобщей радости, большой процент привилегированной нагрузки теперь наблюдался на 8ми ядрах.
Те выводы, которые были получены методом проб и ошибок, приводили к тому, что каждая сетевая плата/IP-адрес может использовать в RSS только 2 процессора. Что же стало причиной такого ограничения? Windows Networking Team ответила на этот вопрос и посоветовала проверить установку значения “RSS rings” для каждой сетевой платы. К слову, этот термин может отличаться у разных производителей сетевых плат. Иногда можно встретить термин “RSS Queues”, который, по сути, обозначает то же самое. После активации данной настройки RSS, каждое обслуживающее работу сетевых плат ядро процессора будет зависеть не только от упомянутого выше ключа реестраMaxNumRssCpus, но и от ассоциированного с ним RSS кольца. Иными словами, количество CPU, участвующих в разделении принимаемой сетевой нагрузки (Receive Side Scaling) будет определяться системой, исходя из наименьшего значения одного из параметров: значения ключа реестраMaxNumRssCpus, а так же значения”RSS Rings” установленного в свойствах сетевой карты. Проверка установки сетевой платы “RSS rings” (закладка “Дополнительно” в свойства платы) показала, что значение действительно было установлено в 2, что объясняло, почему только 2 процессорных ядра были использованы для RSS, когда использовалась только одна сетевая плата. Ещё раз напоминаем, что название для установки “RSS rings” может отличаться у разных производителей аппаратных средств. В описанной выше системе каждая сетевая плата поддерживала до 4-х “RSS rings”, таким образом, максимальное число RSS ядер на каждую сетевую плату может быть 4. (см. Рисунок 1 ниже). Также имейте в виду, что RSS процессоры могут быть назначены только в первой K-Group, если используется Windows 2008 R2 или предшествующие версии ОС. В блоге, там где описана настройка DL980, есть подробности о K-Group и других аспектах рассматриваемой тут темы –Customer Proof of Concept on New HP DL980.
В итоге, в качестве решения проблемы был избран вариант с масштабированием сетевой нагрузки, когда использовались 4 сетевые платы со своими IP адресами. Это позволило получить нужную пропускную способность сетевых интерфейсов, и обеспечить обслуживание RSS таким числом процессоров, которое позволило эффективно обслужить большой сетевой трафик. Конечно, можно использовать более производительные сетевые платы 10Gbps, но при этом следует обязательно задавать правильные значения для “RSS rings”.
В качестве резюме можно выделить два основных момента в настройке RSS для обслуживания нагрузки SQL Server с большим сетевым трафиком:
alex_emilsson
alex_emilssonEmilsson Magazine. Обо всём, кроме политики
Вся приводимая ниже информация, в первую очередь, разумеется, будет относиться к имеющемуся у меня сетевому адаптеру (за неимением других), однако, в основном, все сетевые адаптеры имеют схожие настройки (кроме параметров, специфичных для конкретного производителя/модели), различающиеся, разве что, названиями; поэтому вы с большим успехом можете отнести всё нижеизложенное и к своему адаптеру.
А теперь немного о подопытном. Это сетевой адаптер «Realtek PCIe GBE Family Controller» с чипом «Realtek RTL8111C/D(L) chip (10/100/1000 Mbit)«, интегрированный в материнскую плату «GigaByte GA-G41M-ES2L rev. x.x«<даже диагностические программы выдают именно ревизию "x.x", хотя по цветовой маркировке разъёмов это вылитая "1.0">. Причём, судя по информации с сайта GigaByte, это довольно распространённый вариант для их материнских плат. Адаптер используется на PC под управлением ОС Windows XP SP2, «отupdateнной» до SP3, а также под управлением Windows 7, на которую был установлен SP1 (использовалась версия для x86, хотя для x64 разницы нет). Параметры, специфичные для конкретной ОС, будут помечены в тексте вот так: «< WinXP >» или «< Win7 >«.
Примечания:
Задействовать этот параметр можно только, если все устройства в сети а) поддерживают большие кадры и б) сконфигурированы на использование кадров ОДНОГО размера;
Имейте в виду, что различные адаптеры и сетевые устройства могут по-разному вычислять размер большого кадра (например, включать или не включать размеры дополнительных заголовков);
Наиболее эффективно используют эту технологию сетевые адаптеры, работающие на скоростях 1 Гбит/с и 10 Гбит/с. Известно, что использование больших кадров на скоростях 10/100 Мбит/с на некоторых адаптерах приводит к потере производительности или даже обрыву связи;
Не все ОС могут работать с кадрами размером больше 4K, т.к. это может приводить к перегрузке сети при больших объёмах трафика;
////////WIN7///////Уменьшение числа буферов приёма/передачи менее 256 приводит к обрыву связи при использовании больших кадров.
Описание:
Разрешает или запрещает опцию включения по сети (WOL) компьютера после его выключения.
Описание:
Управляет общей функцией энергосбережения. Для Realtek состояние этой функции можно узнать с помощью «Realtek Ethernet Diagnostic Utility» (см. рис.)
Описание:
Позволяет адаптеру проверять контрольную сумму для принимаемых пакетов (Rx) и вычислять контрольную сумму для отправляемых пакетов (Tx). Включение этой опции может повысить производительность сети и снизить загрузку CPU. Если опция отключена, расчёт и проверку контрольной суммы выполняет ОС.
Описание:
Позволяет адаптеру выполнять задачу фрагментирования пакетов TCP на допустимые кадры Ethernet. Поскольку контроллер адаптера может выполнять фрагментирование гораздо быстрее, чем программное обеспечение ОС, то эта опция может повысить производительность передачи данных. Кроме того, адаптер использует меньше ресурсов CPU.
Описание:
Замещает виртуальный, назначенный пользователем MAC-адрес адаптера. Эта настройка не замещает реальный физический (аппаратный) MAC-адрес адаптера.
Примечание:
Если вы оставите поле «Значение» пустым (при установленном в это значение переключателе), также будет использован исходный MAC-адрес адаптера.
Описание:
Определяет начальную скорость соединения после WOL (далее, видимо устанавливается значение из параметра «Скорость и дуплекс«).
Описание:
Добавляет дополнительные 4 байта к Ethernet-фрейму (кадру), содержащие информацию о приоритете пакета и идентификаторе VLAN, которой этот пакет принадлежит. Т.е. данная опция разрешает аппаратное тегирование VLAN средствами адаптера.
Примечание:
Разумеется, эта опция имеет смысл только при установленной VLAN.
Описание:
Разрешает адаптеру генерировать или отвечать на специальные кадры управления потоком, которые помогают регулировать сетевой трафик.
Сеть может оказаться перегруженной, если входящие пакеты приходят быстрее, чем устройство их может обработать, и в результате происходит потеря пакетов до тех пор, пока условия, способствующие перегрузке не будут устранены. Механизм управления потоком позволяет обойти эту проблему и исключает риск потери пакетов.
Если происходит ситуация, потенциально способствующая перегрузке сети, адаптер генерирует кадр управления потоком, который заставляет устройство на другом конце линии немедленно приостановить передачу и подождать в течение небольшого случайного отрезка времени перед попыткой возобновления передачи.
Примечание:
Для получения преимущества от управления потоком, оба адаптера должны поддерживать это свойство.
Описание:
Определяет доступные возможности WOL.
Описание:
По смыслу эти параметры представляют тот же самый функционал, что и параметр «Функции включения по сети«; просто здесь WOL настраивается для «Pattern Match» и «Magic Packet» по отдельности.
Описание:
Для обеспечения целей энергосбережения, драйвер может автоматически отключить гигабитную скорость, когда сетевой кабель переподключён.
Описание:
Задаёт количество буферов памяти, используемых адаптером при отправке данных. Увеличивая это значение, можно повысить производительность адаптера; правда, при этом также возрастает расход системной памяти. Поэтому, если производительность не является критическим параметром, используйте значение по умолчанию.
Описание:
По смыслу эта группа параметров аналогична «Контрольной сумме разгрузки. «; здесь обработка контрольных сумм настраивается отдельно для TCP и UDP протокола IP обеих версий.
Описание:
По смыслу это параметр «Тегирование 802.1Q/1p VLAN» с более гибкими возможностями настройки.
Примечание:
На некоторых сетевых и/или системных конфигурациях при включенных параметрах группы «Разгрузка при большой отправке. » наблюдается существенная деградация производительности. В этом случае значения всех параметров «Разгрузка при большой отправке. » необходимо отключить (обычно это помогает решить проблему).
Понравилась эта и/или другие мои статьи?
Друзья, тогда предлагаю вам принять посильное участие в улучшении моего журнала. Что можете сделать именно Вы? Для начала, оставьте хотя бы комментарий! Это покажет, что Вы не равнодушны к моему «творчеству». А мне будет приятно, в свою очередь, осознать, что, то что я делаю, нужно не только мне, но и кому-то ещё, например, друзья, Вам! И это будет неплохим стимулом для написания новых статей, определении новых тем и т.д. Далее, Вы можете подписаться на мой блог и стать моими постоянными читателями! Это стало бы дополнительной моральной поддержкой для меня в плане моего творчества.