Нередко системные администраторы и разработчики сталкиваются с парадоксальной ситуацией: пользователи жалуются на длительные зависания клиентского интерфейса 1С (открытие форм документов по 30–60 секунд, задержки ввода данных в строки табличной части), однако монитор производительности сервера показывает минимальную утилизацию CPU и ОЗУ. Разберем основные причины такого поведения и пошагово устраним проблемы производительности.
1. Профайлинг вызовов и анализ кода управляемых форм
В управляемом приложении отрисовка интерфейса напрямую зависит от объема и частоты клиент-серверных вызовов. Выполним замер производительности в конфигураторе на проблемном рабочем месте:
Откроем пользовательский сеанс «1С:Предприятие» и воспроизведем проблемный сценарий (например, открытие формы списка или редактирование ячейки).
Остановим замер и проанализируем строки с наибольшим удельным весом по времени.
Часто в типовых конфигурациях (например, в модулях подсистемы электронных счетов-фактур) при каждом открытии формы или обновлении динамического списка происходит динамическое подключение внешней обработки из хранилища. Серверные вызовы вида ЭСФВызовСервера.ИспользоватьВнешнююОбработку() и ЭСФВызовСервера.ПодключитьВнешнююОбработку() приводят к постоянной пересборке контекста и многократной сериализации данных.
Для исключения искажений, вызванных накопленным пользовательским кэшем настроек динамических списков и форм, можно очистить персональные настройки пользователя с помощью внешней обработки:
2. Контроль дисковой подсистемы и длины очереди диска
Низкий процент общей загрузки процессора часто маскирует ожидание дискового ввода-вывода (I/O Wait). Проанализируем счетчики производительности диска в системном мониторе:
Откроем Системный монитор (Performance Monitor) в Windows Server.
Добавим счетчик Средняя длина очереди диска (Avg. Disk Queue Length) для физических и логических дисков.
Оценим показатели: если среднее значение превышает 0.5–1.0, а пиковые значения достигают 7–10, дисковая подсистема не справляется с потоком случайного чтения/записи, и процессы rphost.exe и sqlservr.exe переходят в состояние блокирующего ожидания.
3. Диагностика разрастания сеансовых данных snccntx
В каталоге данных кластера 1С (srvinfo\reg_XXXX\snccntx...) могут лавинообразно формироваться файлы вида snccntx.00000XXX.dat объемом по несколько десятков мегабайт каждый. Это происходит по следующим причинам:
Использование 32-разрядного сервера 1С: адресное пространство рабочего процесса ограничено 2–3 ГБ. При приближении к лимиту памяти платформа принудительно сбрасывает контекст сеансов на диск, вызывая жесткие дисковые задержки.
Интенсивная сериализация: частое сохранение больших структур данных во временные хранилища и сеансовые переменные.
Для исправления ситуации выполним следующие действия:
Перейдем на использование 64-разрядного сервера 1С:Предприятие, чтобы снять ограничение на объем виртуальной памяти рабочего процесса.
Если переход невозможен немедленно, в консоли администрирования кластера 1С настроим параметры: зададим Допустимый объем памяти и Интервал перезапуска рабочих процессов, а также ограничим количество соединений на один рабочий процесс, распределив нагрузку между несколькими процессами rphost.
4. Разделение ролей сервера 1С и СУБД
Совместная работа сервера 1С и MS SQL Server на одном сервере с небольшим объемом оперативной памяти (16 ГБ и менее) приводит к конкуренции за ресурсы:
По умолчанию SQL Server резервирует под свой кэш всю доступную оперативную память, в результате чего процессы 1С вытесняются в файл подкачки (swap).
Ограничим максимальный объем памяти для экземпляра SQL Server в SQL Server Management Studio (свойство Max Server Memory), оставив запас оперативной памяти для процессов 1С и операционной системы.
При возможности вынесем сервер приложений 1С и сервер СУБД на отдельные физические или виртуальные серверы.
5. Требования к частоте процессора и планам электропитания
Управляемые формы критически чувствительны к однопоточной производительности процессора, поскольку логика построения формы и сериализации выполняется последовательно:
Многоядерные процессоры с низкой базовой частотой (около 2.0 ГГц) показывают значительно худшие результаты для управляемого интерфейса, чем процессоры с частотой 3.0 ГГц и выше.
В настройках BIOS/UEFI сервера и в панели управления операционной системы обязательно переключим схему управления питанием на Высокая производительность (High Performance), отключив механизмы динамического энергосбережения ядер (C-States, P-States).
6. Настройка исключений антивируса и сетевых параметров
Постоянная запись файлов кэша и сеансовых данных создает высокую нагрузку на дисковые фильтры антивирусных систем:
Добавим в исключения постоянного антивирусного сканирования каталоги кластера 1С (srvinfo), временные каталоги пользователей службы (AppData\Local\Temp) и каталоги баз данных SQL.
Исключим из мониторинга исполняемые файлы ragent.exe, rmngr.exe, rphost.exe и sqlservr.exe.
На стороне ОС отключим механизмы разгрузки сетевого стека, вызывающие задержки при обработке коротких пакетов тонкого клиента, выполнив в командной строке:
netsh int tcp set global chimney=disabled