Состояние масштабирования на стороне приема windows 7 что это

Обновлено: 08.07.2024

Несколько лет назад, работая в IT отделе одной компании, столкнулся я с одной проблемой. Заключалась она в невозможности копирования по сети файлов большого размера. При попытке скопировать\перенести файл размером больше 100 МБ процесс намертво вставал, иногда вешая всю систему. Причем, что самое неприятное, проблема проявлялась периодически на разных компьютерах и локализовать ее не удавалось.

В тот раз решить проблему так и не удалось. Через некоторое время она ушла сама, так же неожиданно, как и появилась, и о ней благополучно забыли. И вот, по прошествии некоторого количества лет (и смены нескольких мест работы) я снова увидел знакомые симптомы. Но на сей раз все же удалось раскопать причину подобного поведения.

Теория

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

Для TCP/IP в Windows XP\Server 2003 максимальный размер окна приема фиксирован и по умолчению составляет 64КБ. В Windows 7\Server 2008 оптимальный размер окна приема определяется динамически. Для этого измеряется пропускная способности канала и скорость извлечения приложением данных из окна приема, после чего размер окна адаптируется в соответствии с этими параметрами. Автотюнинг использует масштабирование окна TCP, благодаря чему максимальный размер окна приема составляет 16 МБ.

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

Практика

Как я уже говорил, проблему с автотюнингом очень сложно локализовать. Поэтому, при наличии неопределенных проблем с сетевыми подключениями в первую очередь смотрим настройки TCP. Сделать это можно из командной строки (с повышенными привилегиями) командой:

netsh interface tcp show global

Здесь нас интересует параметр ″Уровень автонастройки окна получения″ (англ. Receive Window Auto-Tuning Level). Он может принимать значения:

Можно попробовать подобрать нужный уровень, например попробовать higlyrestricted , а если не помогает, то отключить:

netsh interface tcp set global autotuninglevel=disabled

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

Проблема с автотюнингом присутствует в операционных системах Windows Vista, Windows 7, Windows Server 2008 и 2008 R2. По Windows 8 и Server 2012 пока данных нет, хотя автотюнинг в них есть и используется. Возможно всплывет позже 🙂

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

Конфигурация RSS-канала

Поддержка RSS доступна на вкладке «Дополнительно» окна свойств адаптера. Если ваш адаптер или операционная система не поддерживают RSS-канал, Настройка RSS не отображается.

Сотрудничество

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

Известные проблемы

В ОС Windows Server 2012 * Настройка RSS для ближайших процессоров может привести к сбоям при передаче и получении

В ОС Windows Server 2012 установка дополнительного параметра для профиля балансировки загрузки RSS-канала может значительно снизить загрузку центрального процессора. Однако в некоторых конфигурациях системы (например, в системе с большим количеством портов Ethernet, чем у ядер процессоров), ближайший параметр процессора может привести к сбоям при передаче и получении. Установите * Рсспрофиле Configuration в нумаскалингстатик , чтобы обойти эту проблему.

Неисправное подключение и возможна нестабильность системы

Если в вашей системе установлены сетевые устройства, отличные от Intel, которые поддерживают масштабирование на стороне заказчика, ключевое слово рссбасекпу могло быть изменено со значения по умолчанию, равного 0x0, для указания логического процессора. Если это ключевое слово было изменено, устройства, основанные на контроллерах Intel® 82598 или 82599 10 Gigabit Ethernet, могут не передавать трафик. Попытка внести изменения в драйвер в этом состоянии может привести к нестабильной работе системы. Присвойте параметру Рссбасекпу значение 0x0 или значение, соответствующее физическому процессору, и перезагрузите систему, чтобы устранить проблему.

Значение масштабирования «получение стороны» пусто

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

Использование ЦП выше ожидаемого

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

200ms.
Начиная с Vista данный параметр изменен и может быть плавающим, т.е. система может сама определять его размер, в зависимости от скоростных возможностей, между сервером и клиентом, так как в данном случае подтверждается весь приемный буфер.
Но данный параметр autotuninglevel (RWIN) он работает в паре с параметром Microsoft Compound TCP (CTCP), который призван увеличить количество передаваемых за TCP-сессию данных. CTCP увеличивает темп передачи с одновременным контролем размера окна и пропускной способности. Сервер быстрее достигает максимального темпа передачи и также быстрее восстанавливается при потере пакетов.

Поставщик надстройки контроля перегрузки : ctcp
congestionprovider - одно из следующих значений:
none: использование встроенного стандартного алгоритма контроля перегрузки.
ctcp: использование дополнительного алгоритма контроля перегрузки CTCP.
default: восстановление выбранного поставщика по умолчанию.

Так же есть еще один параметр
Поддержка Chimney-based разгрузки TCP/IP и поддержка netDMA. Chimney позволяет операционной системе переключать IP-стек на карты TOE (TCP Off-load Engine), которые аппаратным путем обрабатывают TCP/IP. Подобный подход позволяет значительно снизить нагрузку на процессор. Тоже самое касается случая масштабирования принимающей стороны, что позволит входящим пакетам распределяться по различным процессорам. NetDMA позволяет механизму DMA (Direct Memory Access), используемого в адаптере, выполнять операции копирования, снова освобождая от этой рутины центральный процессор.

Состояние NetDMA : enabled
Прямой доступ к кэшу (DCA) : enabled

netdma - одно из следующих значений:
disabled: отключение использования NetDMA протоколом TCP/IP.
enabled : включение использования NetDMA протоколом TCP/IP.
default : восстановление состояния системы по умолчанию .

dca - одно из следующих значений:
disabled: отключение прямого доступа к кэшу при использовании NetDMA.
enabled : включение прямого доступа к кэшу при использовании NetDMA.
default : восстановление состояния системы по умолчанию.

Так что тут не все так просто, нужно найти компромисс в этих настройках.

И еще при использовании VPN вы дальше сервера VPN не попадете, т.е. это канал точка точка при котором после регистрации на сервере VPN клиент работает с интернетом только через VPN (т.е. все запросы/ответы идут через него).[/cut]

Ускорить RDP. Ограничиваем размер окна TCP.

Думаю, не ошибусь, если предположу, что с тормозами при работе с удаленным рабочим столом (RDP) сталкивались все, кто с RPD работал. Симптомов тормозов может много: медленно передает файлы через буфер обмена, долго печатает, медленно отрисовывается экран при прокрутке, особенно если просматривать тяжелые сайты, нагруженные графикой, pdf, состоящих из сканов и т.п. Соответственно, и решения как ускорить RDP тоже бывают разные (см. также "Что такое RDP"). Ниже опишу одно из решений проблемы отрисовки экрана, когда при работе с удаленным RDP, через интернет, а не в пределах локальной сети, прокрутка документов, перемещение объектов рабочего стола, масштабирование в документах вызывает существенный дискомфорт - все дергается, нет плавности движений.

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

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

На Windows сервере RDP:

1. проверьте, что сейчас настроено:

> netsh interface tcp show global

Запрос активного состояния.

Глобальные параметры TCP
------------------------------------------------------
Состояние масштабирования на стороне приема : enabled
Состояние разгрузки канала : automatic
Состояние NetDMA : enabled
Прямой доступ к кэшу (DCA) : disabled
Уровень автонастройки окна получения : normal
Поставщик надстройки контроля перегрузки : none
Мощность ECN : disabled
Отметки времени RFC 1323 : disabled
** Параметр autotuninglevel выше - это результат переопределения всех локальных
конфигураций и конфигураций политик по крайней мере на одном профиле эвристикой масштабирования окон.

Нас интересует "Уровень автонастройки окна получения" (autotuninglevel, см. чуть ниже). По-умолчанию, normal, т.е. грубо - "автонастройка".

Возможные варианты параметра autotuninglevel :

disabled: фиксация значения окна приема по умолчанию.
highlyrestricted: разрешение на увеличение окна приема относительно значения по умолчанию, но очень незначительное.
restricted: разрешение на увеличение окна приема относительно значения по умолчанию, с ограничением увеличения при некоторых сценариях.
normal: разрешение на увеличение окна приема в соответствии с требованиями большинства сценариев.
experimental: разрешение на увеличение окна приема в соответствии с требованиями экстремальных сценариев.

В нашем случае можно проверить эффект от вариантов disabled и highlyrestricted.

> netsh interface tcp set global autotuninglevel=highlyrestricted

и перезагружаем сервер. После перезагрузки вы можете увидеть улучшения. Если нет - возможно надо попробовать:

> netsh interface tcp set global autotuninglevel=disabled

или у вас есть иные причины проблем с RDP.

В моем случае изменения вносились на двух серверах Windows 2012R2, а не на клиенте, т.к. проблемы были сразу у всех клиентов. Вполне возможно, что кому-то правильнее делать эти изменения на клиенте, чтобы не затрагивать остальную работу сервера ограничением окна tcp.

Также проверял эффект в локальной сети - на Windows 7 в локалке эффект привел к незначительному увеличению рывков, ускорять уже было мало что, но плавность стала хуже. Чуть-чуть. Возможно, это из-за того, что при удаленной работе через интернет RDP уже и так зарезано и мы его лишь тюнигуем, а в локальной сети проблем нет и я просто зарезал часть возможностей. Удачи в экспериментах, оставляйте отзывы о результатах или свои мнения.

Читайте также: