Maximum number of rss queues что это

Максимальное число очередей RSS — что это?

Максимальное число очередей RSS — настройка, позволяющая выставить обрабатываемое количеств потоков RNIC-адаптера.

Данная настройка определяет, сколько потоков можно использовать RNIC-адаптеру. Какое именно количество — можно узнать в характеристиках адаптера. Если выставит больше, чем нужно — может быть снижение сетевой производительности. Также были случаи некорректно работы опции при использовании неактуальных драйверов.

RNIC (RDMA Network Interface Controller) — сетевой адаптер с аппаратным ускорением технологии прямого доступа к памяти RDMA. Это удаленный доступ к оперативной памяти, который имеет сетевая карта. Данные технологии используются в серверных конфигурациях, на обычных домашних компьютерах эти настройки нет смысла использовать. Да и вряд ли они будут на обычных сетевых картах типа Realtek.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Включение модерации прерываний

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

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

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

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

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

Установите для компьютера BIOS высокий уровень производительности с отключенными состояниями C. Однако имейте в виду, что это зависит от системы и BIOS, и некоторые системы обеспечивают большую производительность, если операционная система управляет электропитанием. Вы можете проверка и настроить параметры управления питанием из Параметры или с помощью команды powercfg. Дополнительные сведения см. в разделе «Параметры командной строки Powercfg».
Задайте для профиля управления питанием операционной системы высокий уровень производительности.

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

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

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

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

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

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

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

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

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

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

В Windows Vista, Windows Server 2008 и более поздних версиях Windows стек сети Windows использует функцию, которая называется уровнем автоматической настройки окна приема TCP для согласования размера окна получения TCP. Эта функция может согласовывать определенный размер окна получения для каждого tcp-соединения во время подтверждения TCP.

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

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

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

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

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

Менее 1 мегабит в секунду (Мбит/с): 8 килобайт (КБ)
1 Мбит/с до 100 Мбит/с: 17 КБ
100 Мбит/с до 10 гигабит в секунду (Гбит/с): 64 КБ
10 Гбит/с или быстрее: 128 КБ

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

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

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

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

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

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

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

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

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

netsh interface tcp show global

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

Querying active state. TCP Global Parameters ----- Receive-Side Scaling State : enabled Chimney Offload State : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : default ECN Capability : disabled RFC 1323 Timestamps : disabled Initial RTO : 3000 Receive Segment Coalescing State : enabled Non Sack Rtt Resiliency : disabled Max SYN Retransmissions : 2 Fast Open : enabled Fast Open Fallback : enabled Pacing Profile : off

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

netsh interface tcp set global autotuninglevel=

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

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

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

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

Get-NetTCPSetting | Select SettingName,AutoTuningLevelLocal

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

SettingName AutoTuningLevelLocal ----------- -------------------- Automatic InternetCustom Normal DatacenterCustom Normal Compat Normal Datacenter Normal Internet Normal

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

Set-NetTCPSetting -AutoTuningLevelLocal

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

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

Уровни автоматической настройки

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

Уровень	Шестнадцатеричное значение	Комментарии
Обычный (по умолчанию)	0x8 (коэффициент масштабирования 8)	Установите окно получения TCP для увеличения размера, чтобы соответствовать почти всем сценариям.
Выключено	Нет доступных коэффициентов масштабирования	Задайте окно получения TCP по умолчанию.
С ограниченным доступом	0x4 (коэффициент масштабирования 4)	Задайте для окна получения TCP значение по умолчанию, но ограничивает такой рост в некоторых сценариях.
Строго ограниченное	0x2 (коэффициент масштабирования 2)	Задайте для окна получения TCP значение, превышающее значение по умолчанию, но сделайте это очень консервативно.
Экспериментальный	0xE (коэффициент масштабирования 14)	Установите окно получения TCP, чтобы вырасти для удовлетворения экстремальных сценариев.

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

обычный (состояние по умолчанию)

Frame: Number = 492, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=. S., SrcPort=60975, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=4075590425, Ack=0, Win=64240 ( Negotiating scale factor 0x8 ) = 64240 SrcPort: 60975 DstPort: Microsoft-DS(445) SequenceNumber: 4075590425 (0xF2EC9319) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: . S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x8 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x8 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 8 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:

Frame: Number = 353, Captured Frame Length = 62, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet Total IP Length = 48 - Tcp: [Bad CheckSum]Flags=. S., SrcPort=60956, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2315885330, Ack=0, Win=64240 ( ) = 64240 SrcPort: 60956 DstPort: Microsoft-DS(445) SequenceNumber: 2315885330 (0x8A099B12) AcknowledgementNumber: 0 (0x0) + DataOffset: 112 (0x70) + Flags: . S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( ) = 64240 ----------------------------------------> TCP Receive Window set as 64K as per NIC Link bitrate. Note there is no Scale Factor defined. In this case, Scale factor is not being sent as a TCP Option, so it will not be used by Windows. Checksum: 0x817E, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + NoOption: + SACKPermitted:

Frame: Number = 3, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=. S., SrcPort=60890, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1966088568, Ack=0, Win=64240 ( Negotiating scale factor 0x4 ) = 64240 SrcPort: 60890 DstPort: Microsoft-DS(445) SequenceNumber: 1966088568 (0x75302178) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: . S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x4 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x4 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 4 -------------------------------> Scale factor, defined by AutoTuningLevel. + NoOption: + NoOption: + SACKPermitted:

Frame: Number = 115, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=. S., SrcPort=60903, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=1463725706, Ack=0, Win=64240 ( Negotiating scale factor 0x2 ) = 64240 SrcPort: 60903 DstPort: Microsoft-DS(445) SequenceNumber: 1463725706 (0x573EAE8A) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: . S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0x2 ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0x2 Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 2 ------------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:

Frame: Number = 238, Captured Frame Length = 66, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[D8-FE-E3-65-F3-FD],SourceAddress:[C8-5B-76-7D-FA-7F] + Ipv4: Src = 192.169.0.5, Dest = 192.169.0.4, Next Protocol = TCP, Packet Total IP Length = 52 - Tcp: [Bad CheckSum]Flags=. S., SrcPort=60933, DstPort=Microsoft-DS(445), PayloadLen=0, Seq=2095111365, Ack=0, Win=64240 ( Negotiating scale factor 0xe ) = 64240 SrcPort: 60933 DstPort: Microsoft-DS(445) SequenceNumber: 2095111365 (0x7CE0DCC5) AcknowledgementNumber: 0 (0x0) + DataOffset: 128 (0x80) + Flags: . S. ---------------------------------------------------------> SYN Flag set Window: 64240 ( Negotiating scale factor 0xe ) = 64240 ---------> TCP Receive Window set as 64K as per NIC Link bitrate. Note it shows the 0xe Scale Factor. Checksum: 0x8182, Bad UrgentPointer: 0 (0x0) - TCPOptions: + MaxSegmentSize: 1 + NoOption: + WindowsScaleFactor: ShiftCount: 14 -----------------------------> Scale factor, defined by AutoTuningLevel + NoOption: + NoOption: + SACKPermitted:

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

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

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

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

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

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

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

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

Как включить Receive Side Scaling (RSS) на сетевом интерфейсе

Receive Side Scaling

Настройка серверов windows и linux

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали, как производится чистая установка Windows 12 с последующей настройкой. Идем далее и сегодня я хочу с вами разобрать одну интересную опцию, которая присутствует на современных сетевых картах, призванную сильно повысить производительность скачивания данных. Речь пойдет про Receive Side Scaling (RSS) или как его еще называют в российской локализации «Состояние масштабирования на стороне приема». Уверен, будет интересно, я покажу когда вас может сильно выручать данный функционал.

Что такое Receive Side Scaling (RSS)

Receive-Side Scaling (RSS) State, или состояние масштабирования на стороне приема, является функцией сетевых адаптеров и операционных систем, которая позволяет распределить обработку входящих сетевых пакетов по нескольким ядрам процессора. Это позволяет повысить производительность сетевой обработки и улучшить масштабируемость системы.

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

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

Примеры использования RSS

Представим себе обычное, рабочее окружение, где есть лес Active Directory и виртуальная инфраструктура. На части виртуальных машин было замечено:

- Высокая загрузка CPU
- Низкая производительность сети и/или большое время отклика на пинг
- Могут наблюдаться тайм-ауты и сбои подключения.
- Количество виртуальных и физических сетевых карт на этот вопрос не влияет
- Эта проблема возникает с различными типами виртуальных сетевых адаптеров ( E1000, VMXNET2 и VMXNET3)
Начиная с Windows 8.1 и выше, а также Windows Server 2012 R2 и выше, технология состояния масштабирования на стороне приема включена по умолчанию

Как проверить и включить RSS через графический интерфейс

Самый понятный для большинства метод определения текущего состояния Receive Side Scaling на вашем сетевом интерфейсе, это использование оснастки «Диспетчера устройств«. Его можно запустить кликнув правой кнопкой мыши по кнопке «Пуск«.

В итоге у вас откроется окно со списком всех ваших устройств. Вам необходимо найти пункт «Сетевые адаптеры«. В списке выберите необходимый сетевой интерфейс и откройте его свойства. Перейдите на вкладку «Дополнительно«. В поле свойство найдите строку Receive Side Scaling. Выбрав ее вы увидите текущее значений. В моем случае видно, что она активирована.

Как проверить и включить RSS через командную строку

Сразу оговорюсь, что это настройка глобальная для операционной системы Windows и если она активна, это не означает, что на уровне отдельной сетевой карты RSS не отключен, я приведу такой пример, когда буду описывать PowerShell.

netsh int tcp show global

Тоже самое можно посмотреть и для списка удаленных серверов. Для этого достаточно иметь список имен и воспользоваться PowerShell. Вот пример скрипта:

# Путь к файлу со списком серверов
$serverListPath = «C:\Temp\servers.txt»

# Чтение списка серверов из файла и помещение их в переменную
$servers = Get-Content $serverListPath

# Цикл для выполнения команды на каждом сервере
foreach ($server in $servers) # Выполнение команды netsh на сервере и сохранение вывода в переменную
$output = Invoke-Command -ComputerName $server -ScriptBlock netsh int tcp show global
>

# Парсинг вывода команды для получения строки с Receive-Side Scaling State
$receiveSideScalingState = $output | Where-Object

# Вывод результата в виде имя сервера, имя сетевого интерфейса и строки с Receive-Side Scaling State
$receiveSideScalingState | ForEach-Object #$interfaceName = ($_ -split «:\s+»)[0]
$state = ($_ -split «:\s+»)[1]
Write-Host «Сервер: $server, Receive-Side Scaling State: $state»
>
>

Теперь, чтобы включить глобально Receive Side Scaling (RSS), вам нужно выполнить вот такую команду:

netsh int tcp set global rss =enabled
netsh int tcp set global rss =disabled

Как видите все прекрасно работает и состояние масштабирования на стороне приема поменяло статус.

Как проверить и включить Receive Side Scaling с помощью PowerShell

Для того, чтобы получить статус RSS по всем сетевым интерфейсам, вы должны открыть PowerShell от имени администратора и ввести вот такую команду:

Get-NetAdapterRss -Name «*»

��За место «*» вы можете указать точное имя сетевого интерфейса, тогда информация будет только по нему.

Как видно в моем примере, состояние масштабирования на стороне приема имеет значение «False«. Значит оно выключено.

Если вы хотите массово проверить большой список серверов на состояние Receive Side Scaling, то подготовьте список в отдельном текстовом файле, где каждая строка это отдельное имя. После этого выполните данный скрипт.

# Указываем путь к файлу, содержащему список серверов
$serverListFile

# Читаем список серверов из файла и помещаем их в переменную
$servers = Get-Content $serverListFile

# Проходимся по каждому серверу в списке
foreach ($server in $servers) # Получаем состояние работы RSS на сервере
$rssStatus = Get-NetAdapterRss -CimSession $server

# Проходимся по каждому сетевому интерфейсу на сервере
foreach ($interface in $rssStatus) # Выводим результат в виде имени сервера, имени сетевого интерфейса и состояния работы RSS
Write-Host «Сервер: $server, Интерфейс: $($interface.Name), Состояние RSS: $($interface.Enabled)»
>
>

На выходе получаем вот такую таблицу.

Для включения RSS есть командлет Enable-NetAdapterRss. Чтобы активировать данный функционал, выполните.

Enable-NetAdapterRss -Name «*»

В данном примере RSS будет активирован на всех сетевых картах, если хотите выполнить на определенной сетевой карте, то команда будет такой:

Enable-NetAdapterRss -Name «Имя сетевого адаптера»

Вот еще дополнительные команды, которые могут пригодится.
- ✅Показать все свойства RSS для указанного сетевого адаптера
Get-NetAdapterRss -Name «Имя конкретного интерфейса» | Format-List -Property «*»
- ✅Вывести все сетевые адаптеры с поддержкой RSS и его включенным состоянием
Get-NetAdapterRss -Name «*» | Where-Object -FilterScript < $_.Enabled >
- Чтобы выключить Receive Side Scaling вам необходимо воспользоваться командлетом Disable-NetAdapterRss. В данном примере я отключу RSS на всех сетевых интерфейсах.
Disable-NetAdapterRss -Name «*»

RSS-очереди

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

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

По умолчанию количество NumberOfReceiveQueues равно, количеству ваших сокетов.

Поменять «Maximum Number of RSS Queues» можно через диспетчер устройств.

Или же через PowerShell. Чтобы изменить количество очередей RSS на адаптере сетевой карты, используйте команду Set-NetAdapterRss с параметром -NumberOfReceiveQueues

Set-NetAdapterRss -Name * -NumberOfReceiveQueues 4

Чтобы указать диапазон CPU, который сетевой адаптер может использовать для RSS, используйте команду Set-NetAdapterRss с параметрами -BaseProcessorNumber и -MaxProcessorNumber, чтобы указать нижний и верхний пределы диапазона CPU. Изменение диапазона эффективно изменяет количество ядер CPU, используемых сетевой картой для RSS.

Set-NetAdapterRss -Name * -BaseProcessorNumber 4 -MaxProcessorNumber 6

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

Set-NetAdapterRss -Name * -MaxProcessors 2
- https://kb.vmware.com/s/article/2008925
- http://forum.oszone.net/post-925527-22.html
- https://learn.microsoft.com/en-us/powershell/module/netadapter/get-netadapterrss
- https://learn.microsoft.com/en-us/powershell/module/netadapter/enable-netadapterrss
- https://www.broadcom.com/support/knowledgebase/
Популярные Похожие записи:
- Как включить боковую панель в Chrome, за два клика
- Словарь системного администратора
- Центр обработки данных, основные понятия
- Как отключить телеметрию в Linux
- Различия между физическими ядрами и логическими процессорами
- Как отключить Intel Intelligent Display
Повышение пропускной способности сетевых интерфейсов для SQL Server с помощью настройки параметров RSS

Функциональность 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 с большим сетевым трафиком:

Настройте в Windows максимальное число задействованных для RSS процессоров («starting RSS CPU») руководствуясь рекомендациями в статье: Receive-Side Scaling Enhancements in Windows Server 2008
Для каждой используемой сетевой платы задайте значения «RSS Rings» («RSS Queues») таким образом, чтобы сумма этих значений для всех сетевых плат соответствовала значению MaxNumRssCpu в реестре Windows. Учтите, что максимально возможное значение у разных производителей плат может отличаться. Чтобы обеспечить необходимую производительность обслуживания большого трафика по сети, возможно, придётся обновить драйвера/firmware или установить дополнительные сетевые платы.

Ссылки по теме
- Microsoft: Windows Server + CAL + терминальные подключения по супер ценам
- Microsoft: Лицензионная Windows за 5000 рублей
Похожие публикации: