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

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

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

Шаг 1. Локализация проблемы и замер показателей производительности

Прежде чем приступать к масштабным перенастройкам, исключим фактор субъективной оценки пользователей. Выясним причину задержек с помощью объективных замеров:

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

Если замеры на копиях подтверждают кратное замедление именно на новой платформе, последовательно проанализируем инфраструктурные и платформенные факторы.

Шаг 2. Очистка пользовательского и серверного кэша

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

  1. На клиентских рабочих местах очистим каталоги временных файлов: %AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8 (удаляем папки с длинными буквенно-цифровыми GUID-именами).
  2. На сервере 1С остановим службу агента кластера ragent и очистим кэш сеансов и контекстов (файлы snccntx) внутри служебного каталога srvinfo.
  3. В СУБД MS SQL сбросим процедурный кэш с устаревшими планами выполнения запросов, выполнив команду:

DBCC FREEPROCCACHE;

Шаг 3. Проверка исключений антивируса и защитного ПО

Новая версия платформы устанавливается в отдельный каталог на сервере и клиентах (например, C:\Program Files\1cv8\8.3.10.2299\bin\). Если антивирусное ПО или Защитник Windows были настроены на старые пути, они начинают сканировать в реальном времени все запущенные исполняемые файлы и дисковые операции 1С.

Проверим и добавим в исключения антивируса:

  1. Исполняемые файлы платформы: ragent.exe, rmngr.exe, rphost.exe, 1cv8.exe, 1cv8c.exe.
  2. Каталог данных кластера серверов srvinfo.
  3. Каталоги с файлами баз данных и журналов транзакций СУБД (файлы .mdf, .ldf, .ndf).
  4. Временные каталоги операционной системы (папки Temp системной учетной записи службы 1С).

Шаг 4. Оптимизация параметров MS SQL Server под требования 1С

Поведение оптимизатора запросов MS SQL может резко измениться при смене платформы, если сервер баз данных не настроен по стандарту 1С. Выполним следующие настройки СУБД:

  1. Степень параллелизма (MAXDOP): для большинства баз 1С параллелизм запросов приводит к взаимным блокировкам и ожиданиям CXPACKET. Установим параметр Max Degree of Parallelism = 1 в свойствах инстанса SQL Server.
  2. Оценка кардинальности (Cardinality Estimation): на версиях MS SQL Server 2014 и новее новый алгоритм расчета кардинальности может формировать неоптимальные планы для сложных запросов 1С. В параметрах базы данных включим устаревший оценщик через опцию LEGACY_CARDINALITY_ESTIMATION = ON (или через флаг трассировки 9481).
  3. Флаги трассировки: активируем флаг 4199 (включение оптимизаций компилятора SQL) и флаг 2371 (динамический порог автоматического пересчета статистики для больших таблиц).
  4. Регламентные операции: убедимся, что по расписанию выполняются реиндексация и обновление статистик с полной выборкой (FULLSCAN).
  5. Конфигурация TempDB: разделим базу TempDB на несколько файлов данных одинакового размера (по количеству физических ядер процессора, обычно от 4 до 8) с фиксированным шагом автороста в мегабайтах.

Шаг 5. Проверка электропитания и частоты процессора

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

  1. В операционной системе Windows Server переключим схему электропитания на Высокая производительность (High Performance).
  2. На уровне BIOS/UEFI сервера и гипервизора виртуализации отключим энергосберегающие состояния ядер (C-States, C1E) и парковку ядер (Core Parking).

Шаг 6. Анализ прав доступа и условий ограничения на уровне записей (RLS)

Если замедление сопровождается сложными условиями доступа у пользователей, проанализируем пересечение ролей. Использование логического оператора ИЛИ в условиях RLS для разных ролей одного пользователя заставляет СУБД объединять громоздкие подзапросы, что многократно увеличивает время получения данных.

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

Шаг 7. Настройка сетевых протоколов и поиск лицензий

Задержки интерфейса при открытии окон часто вызваны сетевыми таймаутами. Проверим параметры сетевого взаимодействия:

  1. Отключим неиспользуемый протокол IPv6 на сетевых адаптерах сервера и клиентских ПК.
  2. Если сервер 1С и MS SQL расположены на одном физическом сервере, в диспетчере конфигурации SQL Server проверим доступность протокола Shared Memory.
  3. В файле конфигурации клиентской лицензии nethasp.ini отключим широковещательный опрос сети (NH_USE_BROADCAST = Disabled) и явно укажем IP-адрес сервера лицензирования в параметре NH_SERVER_ADDR. Это устранит микрозависания при обращении к ключам защиты.

Если после выполнения всех настроек проблема сохраняется только на конкретном релизе, рассмотрим обновление на более актуальную стабильную версию платформы, в которой устранены возможные ошибки конкретной сборки.

← На главную