Почему тормозит 1С в терминальном режиме при отличных показателях железа и как это исправить?

← На главную

Каждый системный администратор и разработчик 1С рано или поздно сталкивается с парадоксальной ситуацией: физические серверы обладают огромным запасом вычислительной мощности, утилизация процессора не превышает 10%, оперативная память свободна, сетевой пинг между терминальным сервером и сервером приложений составляет 0 миллисекунд, но пользователи массово жалуются на «слайд-шоу» и зависания. Простейшие операции, такие как проведение документа или открытие элемента справочника, которые на самом сервере выполняются за доли секунды, на терминале подвешивают интерфейс на несколько минут.

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

Шаг 1. Локализуем проблему с помощью замера производительности

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

Создадим внешнюю обработку и добавим на форму команду со следующим программным кодом:


&НаСервере
Функция Команда1НаСервере()
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    МассивДанных = Новый Массив;
    Для Сч = 1 По 10000 Цикл
        МассивДанных.Добавить(Сч);
    КонецЦикла;
    ВремяКонца = ТекущаяУниверсальнаяДатаВМиллисекундах();
    ВремяВыполненияВМиллисекундах = ВремяКонца - ВремяНачала;
    Сообщить("Сервер конец: " + ВремяВыполненияВМиллисекундах);
    Возврат МассивДанных;
КонецФункции

&НаКлиенте
Процедура Команда1(Команда)
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    МассивДанных = Новый Массив;
    Для Сч = 1 По 10000 Цикл
        МассивДанных.Добавить(Сч);
    КонецЦикла;
    ВремяКонца = ТекущаяУниверсальнаяДатаВМиллисекундах();
    ВремяВыполненияВМиллисекундах = ВремяКонца - ВремяНачала;
    Сообщить("Клиент конец: " + ВремяВыполненияВМиллисекундах);
    
    ВремяНачала = ТекущаяУниверсальнаяДатаВМиллисекундах();
    Команда1НаСервере();
    ВремяКонца = ТекущаяУниверсальнаяДатаВМиллисекундах();
    ВремяВыполненияВМиллисекундах = ВремяКонца - ВремяНачала;
    Сообщить("Клиент-Сервер конец: " + ВремяВыполненияВМиллисекундах);
КонецПроцедуры

Проанализируем результаты выполнения этого теста в разных условиях:

Запуск непосредственно на сервере приложений 1С (где клиентская и серверная части работают на одном физическом узле):
- Клиент конец: ~11 мс
- Сервер конец: ~12 мс
- Клиент-Сервер конец: ~43 мс
Запуск внутри RDP-сессии на удаленном терминальном сервере (подключенном к серверу 1С по гигабитной локальной сети):
- Клиент конец: ~32 мс
- Сервер конец: ~16 мс
- Клиент-Сервер конец: ~483 мс

Обратите внимание на показатель Клиент-Сервер конец. Разница между локальным запуском и запуском через терминальный сервер составляет более 11 раз! И это при условии, что обычная сетевая утилита ping показывает стабильные 0–1 мс без потерь пакетов. Это явный маркер того, что на уровне операционной системы или сетевого драйвера происходит искусственная задержка передачи сериализованных пакетов платформы 1С.

Рассмотрим детально, какие системные механизмы вызывают этот эффект и как их правильно настроить.

Решение 1. Отключение механизма Dynamic Fair Share Scheduling (DFSS)

В современных операционных системах Windows Server (начиная с версии 2012 и выше) по умолчанию включена технология Dynamic Fair Share Scheduling (DFSS). Ее задача — предотвращать монополизацию ресурсов одним терминальным пользователем. DFSS динамически распределяет процессорное время, дисковую активность и сетевую нагрузку между RDP-сессиями.

Однако алгоритмы этой службы часто распознают лавинообразные сетевые запросы тонкого клиента 1С как вредоносную активность или «захват ресурсов» и начинают искусственно задерживать (дросселировать) пакеты и выделение квантов процессорного времени внутри сеанса. Это приводит к микрофризам интерфейса.

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

Откроем редактор реестра regedit.
Перейдем в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Quota System.
Найдем или создадим параметр типа DWORD с именем EnableCpuQuota и установим его значение равным 0.
Перейдем в ветку реестра, отвечающую за дисковый Fair Share: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk.
Изменим значение параметра EnableFairShare на 0.
Запустим консоль PowerShell от имени администратора и выполним команды для отключения сетевого распределения ресурсов:
```
$temp = (gwmi win32_terminalservicesetting -N "root\cimv2\terminalservices")
$temp.enableNetworkFSS = 0
$temp.put()
```
Перезагрузим терминальный сервер для применения изменений.

Решение 2. Оптимизация аппаратной разгрузки сетевой карты (TCP Offloading)

Технологии аппаратной разгрузки сетевой карты (Large Send Offload, TCP Chimney Offload) призваны переложить часть вычислений по обработке трафика с центрального процессора на чип сетевого адаптера. На практике, особенно при установке системных обновлений или использовании устаревших драйверов, эти функции вызывают эффект «раздувания буфера» (buffer bloating). Небольшие, но критически важные для интерактивной работы пакеты 1С задерживаются в очереди адаптера, ожидая накопления достаточного объема данных для отправки.

Выполним отключение этих функций на терминальных серверах и на сервере приложений 1С. Для этого запустим командную строку от имени администратора и введем команды:


netsh int tcp set global rss=disabled
netsh int tcp set global chimney=disabled
netsh int tcp set global autotuninglevel=disabled

После этого настроим свойства сетевой карты физического сервера через графический интерфейс:

Откроем Диспетчер устройств и перейдем в свойства вашего сетевого адаптера.
Откроем вкладку Дополнительно (Advanced).
Найдем и отключим (переведем в состояние Disabled) следующие параметры:
- Large Send Offload v2 (IPv4)
- Large Send Offload v2 (IPv6)
- TCP Connection Offload (IPv4)
- IPv4 Checksum Offload
Нажмем ОК. В этот момент сетевое подключение может кратковременно разорваться, поэтому работы рекомендуется проводить во внерабочее время.

Решение 3. Настройка приоритета IPv4 над IPv6

По умолчанию Windows Server 2019 при разрешении сетевых имен отдает предпочтение протоколу IPv6. Если в вашей локальной сети IPv6 не настроен бесшовно или отключен лишь частично, при каждом обращении тонкого клиента к имени сервера приложений 1С (например, srv-1c) операционная система терминала сначала отправляет запрос IPv6, ожидает таймаута и только затем совершает откат на IPv4.

Эти микросекундные задержки суммируются при каждом сетевом вызове, превращая работу пользователя в слайд-шоу. Мы можем исправить это двумя способами:

На терминальном сервере откроем файл hosts по пути C:\Windows\System32\drivers\etc\hosts и жестко сопоставим IP-адрес сервера 1С с его сетевым именем: 192.168.1.50 srv-1c
Настроим приоритет IPv4 через системный реестр. Перейдем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters и создадим параметр DWORD с именем DisabledComponents и значением 0x20 (это установит приоритет IPv4 над IPv6 без полного отключения протокола, что сохранит стабильность работы системных служб).

Решение 4. Контроль обновлений операционной системы и СУБД

Довольно часто резкое падение производительности совпадает по времени с автоматической установкой обновлений Windows (особенно через WSUS или напрямую из центра обновлений Microsoft). Известны случаи, когда системные обновления ломали сетевые компоненты виртуализации и протоколы шифрования трафика (например, OpenVPN или VipNet).

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

Приостановить автоматическую установку обновлений на критически важных серверах инфраструктуры 1С.
Внедрить регламент обязательного тестирования обновлений на тестовом контуре перед их разворачиванием в рабочей среде. Для этого удобно применять инструмент для автоматического архивирования, обновления и тестирования баз 1С.
В случае выявления проблем — точечно удалить последнее накопительное обновление и проверить, восстановилась ли производительность клиент-серверного теста.

Решение 5. Блокировки из-за перенаправления принтеров (RDP Printer Redirection)

Малоизвестная, но крайне распространенная причина зависания 1С при записи или проведении документов — опрос принтеров. Перед выводом печатной формы или даже просто перед завершением некоторых транзакций платформа 1С синхронно опрашивает параметры принтера по умолчанию, установленного в сессии пользователя.

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

Для решения этой проблемы применим следующие рекомендации:

Отключим перенаправление локальных принтеров в свойствах подключения RDP (вкладка «Локальные ресурсы», снять флаг «Принтеры»).
Если печать необходима, установим на терминальном сервере по умолчанию быстрый виртуальный принтер (например, Microsoft Print to PDF или специализированный PDF-принтер). В этом случае опрос принтера по умолчанию будет происходить мгновенно, а физическое устройство печати пользователь сможет выбрать вручную непосредственно перед выводом документа.

Решение 6. Настройка исключений антивирусного ПО на уровне сети

Простая настройка исключений для файлов баз данных .mdf / .ldf и исполняемых файлов 1С не гарантирует, что антивирус не вмешивается в процесс работы. Современные антивирусные комплексы выполняют глубокую фильтрацию сетевых пакетов (Deep Packet Inspection), сканируя весь входящий и исходящий трафик «на лету».

Сериализованные пакеты метаданных 1С, проходящие через порты кластера (по умолчанию 1540–1591), могут ошибочно классифицироваться антивирусным монитором как подозрительные бинарные потоки, что вызывает колоссальные задержки при их разборе. Для проверки этой гипотезы временно полностью деинсталлируйте (простого отключения служб в интерфейсе часто недостаточно) антивирус на одном из терминальных серверов и повторно запустите наш замер производительности.

Если тест показал нормализацию времени отклика, настройте в антивирусе полные исключения для сетевых портов кластера 1С и исключите процесс 1cv8.exe из контура сетевой фильтрации.