Проблема резкого снижения скорости работы после обновления конфигурации 1С:Зарплата и управление персоналом на релиз 3.1.6.6 является комплексной. Она затрагивает не только пользовательский интерфейс, но и критически важные расчетные механизмы, такие как расчет оценочных обязательств по отпускам. В данной статье мы подробно проанализируем причины «тормозов», разберем технические аспекты работы этой ветки программного продукта и выработаем пошаговый план оптимизации системы.
Рассмотрим ситуацию, когда процедура сравнения и объединения конфигураций затягивается на несколько часов. Одной из неочевидных причин является работа систем защиты (антивирусов) на сервере. При обновлении до версии 3.1.6 объем временных данных, распаковываемых в папку AppData\Local\Temp, значительно увеличивается. Проанализируем механизм: антивирус сканирует каждый новый созданный объект метаданных, что при объеме конфигурации ЗУП 3.1 приводит к колоссальным задержкам.
Рекомендация: перед запуском процесса обновления в тяжелых базах следует временно исключить из проверки антивирусом папки с временными файлами пользователя, под которым запускается конфигуратор, а также каталоги с базами данных.
Выясним причину, по которой система продолжает тормозить даже после того, как пользователи вошли в базу. В ветке 3.1.6 разработчики 1С активно используют механизм отложенного обновления. Это означает, что после технического обновления метаданных конфигурации, заполнение новых регистров и реструктуризация существующих данных происходит в фоновом режиме.
Проверим состояние этого процесса:
Если в списке присутствуют незавершенные процедуры, система будет тратить значительную часть ресурсов сервера на их выполнение параллельно с работой пользователей. Разберем по шагам: необходимо либо дождаться завершения всех процедур, либо запустить их выполнение в несколько потоков через консоль регламентных заданий, если ресурсы сервера позволяют это сделать. Пока статус не сменится на «Все процедуры обновления выполнены», стабильной производительности ждать не стоит.
Одной из самых острых проблем релиза 3.1.6.6 стал расчет оценочных обязательств (резервов) по отпускам. Пользователи отмечают замедление процесса в несколько раз. Проанализируем причину: в данном релизе был изменен алгоритм сбора данных о среднем заработке для расчета остатков отпусков. Программа формирует тяжелый запрос к регистрам расчета, который при отсутствии актуальных индексов или при большом количестве сотрудников (от 500 и выше) начинает «захлебываться».
Если расчет зависает, попробуем выполнить следующие действия на уровне СУБД (для клиент-серверного варианта):
Выполнение команды очистки кэша планов запросов:
-- Выполнять в SQL Management Studio для конкретной базы
DBCC FREEPROCCACHE;
GO
Это заставит SQL Server пересчитать планы выполнения запросов, которые могли стать неэффективными после изменения структуры метаданных в версии 3.1.6.6.
Рассмотрим техническую сторону вопроса, упомянутую в обсуждениях. Работа в 1С v8.3 (Управляемые формы) крайне чувствительна к актуальности статистики SQL. После масштабного обновления версии 3.1.6 многие таблицы физически пересоздаются. Посмотрим, какие операции критически важны:
Проанализируем ситуацию с TempDB. При расчете зарплаты и резервов в ЗУП 3.1 создается огромное количество временных таблиц. Если файл TempDB расположен на медленном диске или имеет малый размер с автоприращением, это станет «бутылочным горлышком».
Если пользователи жалуются на тормоза при прокрутке списков документов или справочников, это часто связано с механизмом RLS (Record Level Security) — ограничением прав на уровне записей. В версии 3.1.6 механизмы проверки прав были обновлены. Рассмотрим, как это исправить:
Проверим версию платформы 1С. Для стабильной работы ЗУП 3.1.6 крайне рекомендуется использовать платформу не ниже 8.3.12.1440. В более ранних версиях наблюдались утечки памяти в рабочем процессе rphost.exe при обработке сложных запросов с RLS. Переход на актуальную платформу часто решает проблему визуальных «фризов» интерфейса.
Разберем ситуацию, когда «ничего не помогает». Очистка кэша — это обязательный ритуал после любого крупного обновления. Важно очищать не только локальный кэш на рабочих станциях пользователей, но и серверный кэш метаданных.
Также проанализируем список активных фоновых заданий. В релизах 3.1.6 было замечено избыточное потребление ресурсов заданием МониторингОсновныхПоказателей. Если оно выполняется слишком часто, попробуем его отключить:
// Пример программного отключения задания через консоль или обработку
Задание = РегламентныеЗадания.НайтиПредопределенное(Метаданные.РегламентныеЗадания.МониторингОсновныхПоказателей);
Задание.Использование = Ложь;
Задание.Записать();
Это освободит ресурсы процессора для пользовательских расчетов.
Подводя итог, отметим, что релиз 3.1.6.6 был одним из первых в ветке и содержал программные ошибки в запросах, которые невозможно исправить только настройками сервера. Как показывает практика и отзывы специалистов, наиболее стабильная работа этой ветки начинается с релиза 3.1.6.37. В нем исправлены критические ошибки в коде формирования запросов для расчета среднего заработка и оптимизирована работа с динамическими списками. Если выполнение всех вышеперечисленных регламентов не дало значимого эффекта, единственным верным решением будет дальнейшее обновление до актуальной и исправленной версии программы.