Каждый администратор и разработчик систем на базе 1С:Предприятие рано или поздно сталкивается с ситуацией, когда мощный современный сервер с огромным запасом аппаратных ресурсов внезапно начинает вести себя непредсказуемо. Тяжелые регламентные операции, такие как закрытие периода или пакетное проведение документов, выполняются за считанные минуты, но при этом рядовые пользователи испытывают постоянный дискомфорт: при вводе данных в обычную строку табличной части (например, при заполнении количества в документе ПересчетТоваров) интерфейс «замирает» на 20–30 секунд, курсор превращается в крутящееся колесо ожидания, а окна программ блокируют работу всей операционной системы в сеансе RDP. При этом графики загрузки процессора, оперативной памяти и дисковой подсистемы сервера показывают околонулевую активность.
В этой статье мы подробно разберем, почему возникают подобные микрофризы и зависания управляемого интерфейса, как локализовать проблему с помощью встроенных инструментов диагностики и какие системные настройки помогут раз и навсегда избавить пользователей от этой проблемы.
Прежде чем приступать к изменению системных настроек, нам необходимо локализовать проблему и понять, где именно происходит задержка — на стороне клиента, при передаче данных по сети или непосредственно на сервере приложений 1С. Для этого мы задействуем штатные механизмы платформы.
Воспользуемся встроенным инструментом отладки. Запустим конфигуратор 1С, подключимся к сеансу проблемного пользователя в режиме отладки и включим замер производительности непосредственно перед тем, как пользователь начнет редактировать форму. Проанализируем полученную таблицу распределения времени выполнения. Нам необходимо обратить внимание на функции, выполнение которых занимает аномально много времени при простом изменении полей ввода.
Если замер производительности показывает, что время уходит на серверные вызовы, нам потребуется настроить Технологический журнал (ТЖ). Для этого в каталоге установки платформы (по умолчанию C:\Program Files\1cv8\conf) создадим файл конфигурации logcfg.xml. Этот файл позволит нам детально отслеживать долгие серверные вызовы (событие CALL) и длительные обращения к СУБД (событие DBMSSQL). Рассмотрим пример простейшей конфигурации logcfg.xml для сбора долгих событий:
<config xmlns="http://v8.1c.ru/v8/config/logcfg">
<log location="C:\1C_Logs\LongCalls" history="2">
<event filter="duration > 5000">
<eq property="Name" value="CALL"/>
</event>
<event filter="duration > 5000">
<eq property="Name" value="DBMSSQL"/>
</event>
<property name="all"/>
</log>
</config>
Этот файл заставит платформу записывать в лог все вызовы и запросы к базе данных, которые выполняются дольше 5 секунд. Анализ этих логов поможет нам сразу определить, виновна ли СУБД или конфигурация зависает на уровне выполнения кода.
Проанализируем специфическую, но крайне распространенную причину зависаний в многосерверных конфигурациях. Если в вашем кластере 1С настроено более одного рабочего сервера и при этом используются программные лицензии, система может начать циклически опрашивать службы лицензирования на разных физических хостах. В моменты интерактивной работы (открытие форм, запись элементов) это приводит к взаимным блокировкам сеансов на время ожидания ответа от менеджера лицензий.
Для решения этой проблемы перейдем в консоль администрирования кластера 1С и настроим Требования назначения функциональности. Мы должны четко распределить роли серверов. Выясним, какой именно сервер должен отвечать за выдачу лицензий, и принудительно зафиксируем это правило, отключив избыточные рабочие серверы от выполнения этой задачи через свойства кластера:
Если пользователи работают через удаленные рабочие столы на базе Windows Server 2016, частой причиной зависания интерфейса является некорректная работа графического конвейера. Управляемые формы 1С активно используют библиотеки рендеринга элементов управления. По умолчанию операционная система пытается использовать аппаратное ускорение видеокарты (даже если физического графического процессора в сервере нет, и используется виртуальный WDDM-драйвер), что приводит к зависаниям вывода изображения у всех пользователей сессии.
Чтобы исправить это, отключим аппаратное ускорение для протокола RDP через редактор локальной групповой политики (команда gpedit.msc):
gpupdate /force в командной строке.При интерактивном вводе данных в формы документов платформа 1С непрерывно взаимодействует с жестким диском, создавая сотни мелких временных файлов в каталогах кэша пользователя и системной папке %TEMP%. Если на сервере установлен антивирус (например, Windows Defender), он перехватывает каждую операцию записи/чтения для проверки файла в режиме реального времени. Это вызывает микрозадержки, которые суммируются и вызывают длительные подвисания интерфейса.
Нам необходимо зайти в настройки антивирусного программного обеспечения и добавить в список исключений:
1cv8.exe, 1cv8c.exe, rphost.exe.C:\Users\*\AppData\Local\1C\ и C:\Users\*\AppData\Roaming\1C\.C:\Users\*\AppData\Local\Temp\.В современных операционных системах Windows Server приоритет отдается сетевым пакетам протокола IPv6. Если в вашей локальной сети IPv6 не настроен должным образом (или не поддерживается сетевым оборудованием), тонкий клиент или платформа 1С при обращении к серверу приложений сначала пытаются установить соединение по IPv6. Не получив ответа, система ожидает системного таймаута (около 20–30 секунд) и только потом переключается на IPv4. Это является классической причиной «замирания» окон при клиент-серверных вызовах.
Для исправления этой проблемы установим приоритет IPv4 над IPv6 через реестр Windows:
regedit.HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters.DisabledComponents и присвоим ему шестнадцатеричное значение 20 (это установит приоритет IPv4 перед IPv6 без полного отключения протокола).Разберем ситуацию с точки зрения разработки. В управляемом приложении критически важно минимизировать объем данных, передаваемых между клиентом и сервером. Документ ПересчетТоваров часто содержит тысячи строк табличной части. Если при изменении колонки количества срабатывает обработчик события ПриИзменении, написанный с использованием неоптимальных директив компиляции, платформа вынуждена сериализовать всю форму и отправлять ее на сервер.
Проанализируем пример неоптимального кода:
&НаКлиенте
Процедура ТоварыКоличествоПриИзменении(Элемент)
// Неоптимально: вызов контекстного серверного метода пересылает всю форму
РассчитатьИтогиНаСервере();
КонецПроцедуры
&НаСервере
Процедура РассчитатьИтогиНаСервере()
// Выполнение расчетов с полным контекстом формы
КонецПроцедуры
Перепишем этот обработчик правильно. Заменим контекстный вызов на бесконтекстный, передавая на сервер только те данные, которые необходимы для расчета конкретной строки. Это кратно снизит объем трафика и нагрузку на серверную часть:
&НаКлиенте
Процедура ТоварыКоличествоПриИзменении(Элемент)
ТекущаяСтрока = Элементы.Товары.ТекущиеДанные;
// Оптимально: передаем только данные конкретной строки в бесконтекстный метод
СтруктураПараметров = Новый Структура("Количество, Цена", ТекущаяСтрока.Количество, ТекущаяСтрока.Цена);
ТекущаяСтрока.Сумма = РассчитатьСуммуНаСервереБезКонтекста(СтруктураПараметров);
КонецПроцедуры
&НаСервереБезКонтекста
Функция РассчитатьСуммуНаСервереБезКонтекста(Параметры)
Возврат Параметры.Количество * Параметры.Цена;
КонецФункции
Если для защиты конфигурации используются аппаратные ключи HASP, платформа 1С при выполнении определенных операций может инициировать процедуру поиска свободных лицензий в локальной сети. По умолчанию поиск осуществляется широковещательными пакетами по всей сети (Broadcast). В случае сложной маршрутизации или блокировок со стороны сетевых экранов этот поиск зависает на время ожидания ответа.
Чтобы избежать этого, настроим файл конфигурации сетевого драйвера защиты nnhasp.ini, который обычно располагается по пути C:\Program Files\1cv8\conf\ (или в каталоге установки конкретной версии платформы). Мы должны жестко прописать адрес сервера лицензирования и отключить широковещательный поиск:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь IP вашего сервера лицензий
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = Disabled
При интерактивной работе пользователей с формами списков и табличными частями система MS SQL Server активно использует системную базу данных tempdb для хранения временных таблиц и результатов промежуточных вычислений 1С. Если параметры tempdb оставлены по умолчанию, база данных может иметь слишком малый исходный размер и некорректно настроенный шаг авторасширения (например, 1 МБ или 10%). В момент нехватки места СУБД полностью блокирует все транзакции пользователей до тех пор, пока физически не увеличит файл базы данных на диске.
Для исправления этой проблемы настроим параметры tempdb через SQL Server Management Studio (SSMS):
tempdb на несколько файлов данных равного размера. Оптимальное количество файлов — по одному на каждое логическое ядро процессора (но не более 8 файлов, если ядер больше).tempdb на самом быстром доступном твердотельном накопителе (SSD NVMe).Выполнив по шагам предложенные системные настройки, мы сможем гарантировать стабильную работу управляемого интерфейса 1С без раздражающих задержек и зависаний форм даже при высокой интенсивности интерактивной работы пользователей.