Ситуация, когда информационная база 1С:ЗУП 3.1 начинает работать крайне медленно при нормальной скорости других баз (БП, ERP, ДО), — довольно распространенная проблема. Рассмотрим типичный случай: проведение документа ИзменениеПлановыхНачислений на 50 сотрудников занимает 4 минуты, а его отмена — 20 минут. При этом анализ технологического журнала указывает на длительные операции в секции SDBL и CommitTransaction. Разберем по шагам, как проанализировать и решить эту проблему.
Проанализируем запись из технологического журнала (ТЖ), которую предоставил автор. Мы видим, что задержка происходит на этапе CommitTransaction при записи формы документа. Это критически важный момент. Длительная фиксация транзакции (десятки и сотни секунд) обычно сигнализирует об одной из трех проблем:
Выясним причину, изучив настройки сервера и базы данных. Если проблема сохраняется даже при разворачивании бэкапа в новой среде, значит, причина кроется либо в самих данных базы, либо в специфических настройках СУБД, которые "подхватывают" эту базу.
Одной из главных причин внезапных тормозов является деградация индексов и неактуальная статистика. Разберем правильную схему обслуживания, так как стандартные рекомендации "из коробки" часто содержат ошибки, такие как использование SHRINK.
Почему нельзя делать SHRINK? Проанализируем операцию сжатия базы. Она физически перемещает страницы данных, что приводит к колоссальной фрагментации индексов (до 90-99%). Если после сжатия не выполнить полную реиндексацию, производительность упадет в разы.
Рассмотрим правильный алгоритм обслуживания, который необходимо настроить в SQL Server Management Studio (SSMS):
REORGANIZE (выполняется онлайн, не блокирует пользователей).REBUILD (в стандартной версии SQL блокирует таблицы, лучше делать ночью).
DBCC FREEPROCCACHE;
GO
Программа 1С:ЗУП 3 крайне требовательна к скорости работы одного ядра процессора и настройкам параллелизма. Посмотрим на показатели теста Гилева. Значение в 22 балла для процессора уровня Xeon Gold или E5-2650 v2 является критически низким. Это указывает на то, что сервер работает в режиме энергосбережения или неправильно настроен SQL.
Настройка MAXDOP:
Для баз 1С крайне рекомендуется ограничивать максимальную степень параллелизма. В настройках сервера MS SQL (параметр Max Degree of Parallelism) установите значение 1. Это заставит SQL выполнять каждый запрос в рамках одного ядра, что предотвратит взаимные блокировки потоков (ожидания CXPACKET), которые часто вызывают тормоза при записи документов в ЗУП.
Очередь пересчетов: В ЗУП 3 существует механизм "Данные к расчету". Если в системе накопилось много невыполненных пересчетов, любая запись кадрового документа будет инициировать тяжелый анализ этих данных. Рассмотрим, как это проверить: перейдите в раздел Зарплата — Сервис — Пересчеты зарплаты. Если там находятся тысячи записей за прошлые периоды, их необходимо удалить. Это часто дает мгновенный прирост скорости проведения документов.
Проанализируем ситуацию с правами доступа. Ограничение прав на уровне записей (RLS) в ЗУП 3 — это очень "дорогостоящая" операция для процессора. При проведении документа на 50 человек система проверяет права доступа к каждому сотруднику через сложные запросы к таблицам прав.
Попробуем диагностировать RLS следующим образом: Выполните проведение проблемного документа под пользователем с Полными правами. Если документ проведется за 10-15 секунд вместо 4 минут, значит, проблема в производительности RLS. В этом случае необходимо проверить в настройках (Администрирование — Настройки пользователей и прав), включен ли "Производительный режим" работы RLS.
Также стоит обратить внимание на расширения. Если в расширениях добавлены подписки на события ПередЗаписью или ПриЗаписи, они могут выполнять неоптимальные запросы в цикле. Для проверки временно отключите все расширения и замерьте скорость работы документа.
Выясним, почему тест Гилева показывает низкие результаты (22 балла). Современные серверные процессоры имеют базовую частоту (например, 2.6 ГГц) и частоту Turbo Boost. Если в Windows Server или в настройках BIOS стоит режим Balanced (Сбалансированный), процессор не будет поднимать частоту для "коротких" запросов 1С.
Обязательно установите режим "Высокая производительность" (High Performance). Это может поднять производительность на 30-50% без вложений в железо.
Для решения проблемы "внезапных" тормозов в ЗУП 3.1 рекомендуем придерживаться следующего чек-листа:
REBUILD индексов. Очистите процедурный кэш командой DBCC FREEPROCCACHE.MAXDOP = 1 и убедитесь, что база tempdb разделена на несколько файлов (по количеству ядер, но не более 8).Соблюдение этих шагов позволит вернуть нормальную скорость работы программы и значительно сократить время закрытия месяца для бухгалтерии.