Мне действительно это понравилось тема о распределении нагрузки от прерываний сетевого адаптера по процессорам, поэтому я решил описать, как это делается в Windows. Disclaimer: судя по некоторым комментариям в предыдущих постах, я должен повторить то, с чего начал в первом посте: я не даю (и не могу дать) общеприменимых рецептов.
Особенно это актуально для продуктивности, где малейшая неучтённая деталь может катастрофически повлиять на результат. Скорее даю рекомендацию: ТЕСТИРОВАНИЕ И АНАЛИЗ.
Цель моего письма — дать людям как можно больше информации для анализа, потому что чем больше вы понимаете, как что-то работает, тем легче найти способы устранения узких мест. Итак, масштабируемость пропускной способности сети.
Требуется Windows Server 2003 SP2+.
Сетевая карта, поддерживающая масштабирование на стороне приема (можно с достаточной степенью уверенности сказать, что подойдет любая серверная сетевая карта, выпущенная за последние 5 лет, или любой сетевой адаптер 1 Гбит+, хотя часто можно увидеть RSS на 100 Мбит).
Установка Windows Server и драйверов на карту.
ВСЕ.
Настройка завершена.
RSS включен по умолчанию во всех версиях Windows, которые его поддерживают.
Тестирование
Возьмем не очень новый сервер Dell с двумя четырехъядерными процессорами Xeon:
На борту имеются две двухпортовые сетевые карты по 1Gb и одна сетевая карта на 10Gb, но 10Gb-свича я не нашел, поэтому установить его не удалось — ну да ладно:
Что интересно в этих картах, так это то, что, хотя они и поддерживают RSS с 8 очередями, они не поддерживают никаких MSI-X даже не MSI. При этом из четырех доступных линий прерываний по выводам каждому сетевому порту выделена только одна (соответственно заставить прерывания поступать на разные процессоры каким-либо образом уже невозможно — это аппаратное ограничение данной конфигурации).
На 10-гигабитной карте прописано то 32, то 64 (на глазок) вектора прерываний, но использовать ее не судьба.
Сможет ли он Индуистское ремесло для запуска игр справиться с задачей? 
На всякий случай проверяем RSS (хотя если его нет, то все равно будет заметно): 
Для начала отключим RSS (после тестирования я его снова включил, но в том же окне) 
и запустите нагрузочный тест:
Два ядра загружены полностью, все остальные простаивают 
Сеть загружена на треть: 
50% одного процессора забито обработкой прерываний, еще 20% того же процессора — обработка DPC. Остальное — это стек tcpip и приложение, отправляющее трафик.
Включите RSS (скриншот выше).
ПРОЦЕССОР: 
Сеть: 
Треть одного процессора забита прерываниями, но ЦОДы прекрасно распараллелены.
В целом при такой конфигурации можно было бы передать около 3-х гигабит (с одной сетевой карты) и только тогда мы столкнулись бы с узким местом.
На всякий случай скажу, что у RSS есть менее известный родственник — Send Side Scaling. Если перед отправкой списка буферов разоблачать хэш-значение, то прерывание после завершения отправки будет доставлено в соответствии с установленными таблицами косвенности.
Здесь вы можете прочитать о RSS и Здесь Есть хорошая презентация в картинках, объясняющая работу RSS. Если вам интересно, могу попытаться своими словами описать механизмы работы RSS, но на мой взгляд, лучше читать первоисточники.
Механизм разгрузки TCP
Если что-то вроде RSS в Linux точно появится (о поддержке нормального аппаратного RSS в Linux упоминаний не нашел: кто знает, дайте ссылку и я обновлю пост).Затем с ПАЛЕЦ НА НОГЕ в линуксе официально все сложно.
Патч от Челси (одного из производителей высококлассных сетевых карт) реализация поддержки TOE была отклонена, а вместо этого некоторые полностью идиотские оправдания (Когда вы читаете, стоит иметь в виду, что BSD и Windows уже много лет имеют нормальную поддержку TOE).
Так что же это такое? TOE — это полная реализация TCPIP на аппаратном уровне: с подтверждением доставки, повторной передачей в случае ошибок, оконным контролем и т. д.: сетевая карта берет данные напрямую из памяти через DMA, разрезает их на пакеты, прикрепляет заголовки и сообщает ( использование прерываний) только в самых крайних случаях.
По умолчанию TOE находится в автоматическом режиме.
Наблюдайте за состоянием разгрузки дымохода: 
Скриншот сделан во время активного тестирования, но статистика показывает, что на сетевую карту не «загрузилось» ни одно соединение (о причинах чуть позже).
Включим принудительно (и через некоторое время запросим статистику): 
И вот причина: на эту сетевую карту можно загрузить только 1024 соединения (а на самом деле система смогла загрузить 1022).
Довольно дорогой ресурс, чтобы можно было все выложить.
Система эвристически пытается обнаружить соединения (получение/передача больших файлов по http, передача содержимого файлов на файловые серверы и т. д.), которые будут жить долго, и выгружает их в первую очередь.
Но давайте посмотрим, что произошло.
Процессор выгружался трижды: 
Количество (и время, проведенное) как ISR, так и DPC сильно сократилось: 
Теги: #Системное администрирование #rss #масштабируемость #масштабируемость #TOE
-
Обзор Павильона Hp Dv4I-2100
19 Oct, 24 -
Вавилов Николай Иванович.
19 Oct, 24 -
Linux.com Взломан
19 Oct, 24 -
Проблема С Запуском Wm
19 Oct, 24 -
Редактор Цветовой Схемы Для Sublimetext 2
19 Oct, 24
