Функциональность 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 или установить дополнительные сетевые платы.
По материалам статьи: Кун Ченг (Kun Cheng) Maximizing SQL Server Throughput with RSS Tuning