Предел одновременных RDP-сессий: где Windows-сервер сдаётся первым

MAATRIX

«Сколько пользователей потянет терминальный сервер на 32 ГБ?» — вопрос, на который нет универсального ответа, хотя его задают так, будто где-то есть таблица с готовым числом. Один и тот же сервер держит 40 бухгалтеров в 1С и захлёбывается на 12 дизайнерах в тяжёлом графическом редакторе. Разница не в железе, а в профиле нагрузки — и посчитать реальный предел для вашего случая можно за один тестовый день, если знать, что именно мерить.

Три предела, которые сходятся в одной точке

У любого RDS-сервера (Remote Desktop Session Host) одновременно действуют три независимых ограничения, и сервер упирается в то, которое наступает раньше остальных:

• Память. Каждая RDP-сессия — это не «окно», а полноценный вход в систему: отдельный десктоп-профиль, оболочка explorer.exe, набор запущенных пользователем приложений, буфер обмена, шрифты, темы. Всё это занимает рабочий набор (working set) в оперативной памяти, и он суммируется линейно по числу сессий поверх базового расхода самой ОС.
• CPU. Ядра делятся между всеми активными сессиями через планировщик Windows. Пока пользователи печатают текст и листают почту — нагрузка на ядро незаметна. Как только несколько человек одновременно формируют отчёт в 1С, пересчитывают таблицу в Excel или рендерят превью в графическом пакете — CPU становится узким местом раньше, чем память успевает закончиться.
• Лицензирование. RDS CAL ограничивает не производительность, а легальность подключения: без роли Remote Desktop Services и купленных клиентских лицензий сервер физически не пустит больше двух одновременных RDP-подключений, независимо от того, сколько у него памяти и ядер. Это разобрано отдельно в статье про лицензирование RDP на несколько пользователей — здесь не повторяем эту часть, а разбираем именно потолок производительности при уже снятом лицензионном ограничении.

Практический вывод: прежде чем считать «сколько сессий влезет по памяти», нужно понять профиль вашей команды — офисный (почта, браузер, Office, лёгкие CRM-клиенты) или тяжёлый (1С с большими отчётами, САПР, графика, видеомонтаж). Для одного и того же объёма RAM эти профили дают разницу в разы по числу пользователей.

Как профилировать типичную сессию по памяти

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

Первый способ — Диспетчер задач с вкладкой «Пользователи», которая показывает суммарный расход CPU и памяти по каждой активной сессии, а не только по процессам:

# Список активных сессий и краткая сводка
query session

# Подробный расход по процессам конкретной сессии (ID из query session)
Get-Process -IncludeUserName | Where-Object { $_.SessionId -eq 3 } |
    Sort-Object WS -Descending |
    Select-Object ProcessName, Id, @{N='RAM_MB';E={[math]::Round($_.WS/1MB,1)}}

Второй, более точный способ — счётчики производительности через perfmon или typeperf, которые агрегируют память по логической сессии, а не по разрозненным процессам:

typeperf "\Terminal Services Session(*)\% Processor Time" `
         "\Terminal Services Session(*)\% Processor Time" -sc 1

Для памяти конкретной сессии удобнее объект Process с фильтром по SessionId, как в примере выше — сложите WS (working set) всех процессов пользователя (explorer.exe, приложения, фоновые агенты вроде антивируса на сессию, если он там висит per-user) и получите реальный, а не табличный расход.

Методика профилирования:

1. Заведите тестового пользователя с точно теми же политиками, профилем и стартовым набором приложений, что у боевых сотрудников.
2. Войдите под ним по RDP, откройте типичный рабочий набор — почту, браузер с рабочими вкладками, 1С или CRM, Office — и поработайте с ним 15-20 минут, а не только запустите и оставьте свёрнутым: холодный старт занижает цифру, приложения дозагружают компоненты по мере использования.
3. Снимите WS по сессии в этот момент — это ваш «типичный профиль». Отдельно зафиксируйте пиковое значение при самой тяжёлой операции (открытие большого отчёта, импорт файла) — пик определяет запас, а не средняя цифра.
4. Повторите для 2-3 сессий одновременно, чтобы учесть общие (shared) страницы кода — DLL и общие библиотеки Windows подгружаются один раз в физическую память и доступны всем сессиям через copy-on-write, поэтому суммарный расход растёт не строго линейно, а с небольшой экономией на общих компонентах после первых нескольких сессий.

Здесь важна честная оговорка: точные мегабайты на сессию у вас будут другими, чем у соседа с тем же набором ПО — версии приложений, число открытых документов, настройки автосохранения и надстройки-плагины (особенно в Excel и Outlook) меняют цифру заметно. Измеренная на вашем стенде цифра — единственная, которой можно доверять.

Формула ёмкости сервера: расчёт под профиль нагрузки

Когда есть измеренный расход на сессию, ёмкость считается вычитанием фиксированных резервов из общей памяти сервера:

Доступно для сессий = RAM_сервера
                     − RAM_ОС_и_служб (база + антивирус + агенты мониторинга)
                     − Резерв_на_пики (буфер под одновременные пиковые нагрузки)

Число_сессий ≈ Доступно_для_сессий / RAM_на_сессию_измеренная

Ориентировочные диапазоны для двух профилей (это именно ориентир для планирования теста, а не гарантированная цифра — проверяйте на своём стенде по методике выше):

Резерв на пики закладывайте отдельно, а не растворяйте в среднем расходе: если 5% сессий одновременно открывают тяжёлый отчёт, а вы посчитали ёмкость только по среднему профилю — именно в этот момент сервер уйдёт в своп, и деградация ударит по всем, а не только по тем, кто формировал отчёт. Практический ориентир — закладывать резерв в 15-25% от расчётной ёмкости под одновременные пики, но конкретный процент зависит от того, насколько синхронно работает команда (бухгалтерия, закрывающая период разом, создаёт больше синхронных пиков, чем разрозненные менеджеры).

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

CPU: ядра, всплески и переключение контекста

По CPU логика расчёта другая, потому что нагрузка не аддитивна так же прямолинейно, как память — она зависит от того, сколько сессий одновременно активно (а не просто открыто) в конкретный момент.

Для офисного профиля типичная сессия потребляет CPU не непрерывно, а короткими всплесками — при вводе текста, переключении окон, открытии документа. Между всплесками ядро простаивает и обслуживает других пользователей. Это позволяет держать заметно больше сессий, чем ядер физически на сервере — планировщик Windows размазывает короткие пики по доступным тактам. Проблема начинается, когда всплески у разных пользователей синхронизируются — например, все формируют отчёт в одно и то же время в конце месяца, — и тогда то, что работало как overcommit CPU (подробнее — в материале про overcommit CPU и памяти), превращается в очередь: каждая сессия ждёт своего кванта времени, интерфейс подвисает у всех одновременно.

Для тяжёлого профиля (рендер, пересчёт больших таблиц, кодирование) допущение о коротких всплесках не работает — там сессия занимает ядро надолго и почти полностью, и планировать нужно ближе к соотношению «одно физическое/виртуальное ядро на 1-2 активные тяжёлые сессии», а не по числу пользователей вообще. Это тот же принцип overcommit, что применяется при распределении CPU между виртуальными машинами на гипервизоре: он оправдан, пока реальная одновременная активность ниже номинала, и перестаёт работать, когда пользователи начинают требовать ресурс синхронно.

Практическая проверка перед запуском в продакшн — счётчик % Processor Time по каждой Terminal Services Session под реалистичной нагрузкой нескольких тестовых пользователей одновременно, а не по одному в лабораторных условиях: переключение контекста между процессами разных сессий даёт накладные расходы, которых не видно при тесте с одним пользователем.

Первые признаки деградации до жалоб пользователей

Деградация RDS-сервера почти всегда видна в счётчиках раньше, чем в тикетах от сотрудников — если, конечно, снимать эти счётчики регулярно, а не постфактум после жалоб.

Субъективно пользователи замечают проблему в такой последовательности: сначала подтормаживает перерисовка окон и курсор «плывёт» с задержкой (первый признак — CPU или сетевая перегрузка канала RDP), затем приложения начинают долго открывать файлы и меню (обычно уже память и своп), и в последнюю очередь — прямые отказы новых подключений или принудительное закрытие неактивных сессий политикой сервера. Если мониторить только последний симптом, вы всегда будете реагировать постфактум, когда часть команды уже работала в раздражающих условиях часами или днями.

Полезная привычка — вести журнал из query session и ключевых счётчиков раз в 15-30 минут в рабочее время хотя бы первые пару недель после запуска сервера, чтобы увидеть форму нагрузки за день (утренний вход всей команды почти всегда самый тяжёлый момент по CPU) и найти реальный потолок, а не полагаться на разовый тест.

Пилотный запуск и постепенное масштабирование

Самый надёжный способ узнать предел конкретного сервера — не расчёт на бумаге, а контролируемый пилот на реальных пользователях с реальными задачами:

1. Стартуйте с подгруппы. Переведите на сервер 30-40% команды, а не всех сразу — так у вас остаётся запас, чтобы откатить решение без остановки работы всего офиса, если что-то пойдёт не так.
2. Мониторьте счётчики из предыдущего раздела ежедневно первую неделю, особенно в момент утреннего входа и в характерные пиковые операции (закрытие периода в бухгалтерии, конец месяца, отчётные даты).
3. Добавляйте пользователей партиями по 5-10, а не по одному — так изменение нагрузки заметно на графиках, и легче связать рост счётчиков с конкретным шагом.
4. Зафиксируйте порог, при котором счётчики начинают устойчиво уходить в тревожную зону — это и есть ваш реальный предел для этого железа и этого профиля нагрузки, а не табличное число из общих рекомендаций.

Если предел достигнут раньше, чем нужно посадить всю команду, у вас два направления, а не одно: нарастить ресурсы одного сервера (upgrade RAM/CPU) или разделить нагрузку на несколько серверов через RD Connection Broker — компонент RDS, который распределяет новые подключения между несколькими RD Session Host по загрузке и держит пользователя привязанным к «его» серверу при переподключении. Второй путь дороже по лицензиям (CAL считаются на пользователя вне зависимости от числа серверов, а вот сама роль и обслуживание фермы серверов — дополнительные накладные расходы), но снимает риск единой точки отказа: при отказе одного сервера фермы часть команды продолжает работать на других. Про общую архитектуру терминального сервера на выделенной VM и когда она оправдана — в статье терминальный сервер на своём гипервизоре, а конкретный пример расчёта для тяжёлого профиля 1С — в разборе терминального сервера для бухгалтерской фирмы.

Отдельно стоит упомянуть профили пользователей: если сервер использует роуминг-профили или FSLogix-контейнеры для персонализации рабочего стола, при первом входе после перезагрузки или после долгого отсутствия профиль пользователя разворачивается заново — это даёт кратковременный всплеск дисковой и CPU-нагрузки, который стоит учитывать отдельно от установившегося потребления, особенно если вся команда возвращается на работу одновременно после выходных.

Частые вопросы