В процессе эксплуатации высоконагруженных баз 1С, особенно на платформе «обычных форм» (как в случае с УТ 10.3), системные администраторы и программисты часто сталкиваются с эффектом «плавающей» производительности. Типичный сценарий: массовое перепроведение документов за большой период начинается очень бодро, но через 5–15 минут скорость падает в несколько раз. Проанализируем причины этого явления и разберем комплекс мер по стабилизации работы системы.
Самая распространенная причина замедления — устаревание статистики распределения данных в таблицах. SQL Server использует статистику для построения оптимального плана выполнения запроса. Когда мы массово перепроводим документы, данные в таблицах движений (регистрах накопления) меняются лавинообразно. План запроса, который был эффективен в начале операции, перестает быть таковым уже через несколько минут.
Решение: Настроим регламентное задание в SQL Server Agent для обновления статистики. Как показывает практика, при интенсивных операциях стандартного ночного обновления недостаточно. Рассмотрим вариант запуска обновления каждые 4 часа или даже чаще в периоды пиковых нагрузок.
Для обновления статистики по всей базе можно использовать команду:
USE [Имя_Вашей_Базы];
EXEC sp_updatestats;
Также проанализируем настройку Auto Update Statistics Statistics Async. Включим асинхронное обновление статистики. Это позволит SQL Server не блокировать запрос пользователя в ожидании новой статистики, а выполнять его по старому плану, параллельно подготавливая новый.
Разберем ситуацию с использованием ядер процессора. По умолчанию MS SQL Server старается выполнить тяжелый запрос, задействовав все доступные ядра (параметр Maximum Degree of Parallelism). В 1С это часто приводит к взаимным блокировкам и ожиданиям на ресурсах процессора.
Решение: Установим ограничение MAXDOP. Для большинства систем 1С рекомендуемым значением является 1 (запрет параллелизма для одного запроса). В некоторых случаях на многопроцессорных серверах можно установить значение 2 или 4, но не более половины ядер одного физического процессора. Это гарантирует, что один тяжелый отчет или проведение документа не «парализует» всю операционную систему.
Выясним причину, связанную с временными таблицами. При перепроведении документов 1С активно использует TempDB. Если эта база состоит из одного файла, возникает очередь на запись (проблема Page Latch).
Решение: Выполним следующие шаги для оптимизации TempDB:
TempDB должно быть равно количеству логических ядер процессора (если ядер больше 8, начнем с 8 файлов).TempDB.TempDB на самом быстром дисковом массиве (лучший вариант — NVMe SSD).Проанализируем механизм автоматического обновления статистики. В старых версиях SQL Server (до 2016) порог обновления составлял 20% изменений в таблице. Если в таблице 10 миллионов записей, то статистика не обновится, пока не изменится 2 миллиона, что критично для 1С.
Решение: Включим флаг трассировки 2371. Он делает порог обновления динамическим: чем больше таблица, тем меньший процент изменений требуется для старта обновления. Это позволяет поддерживать планы запросов в актуальном состоянии даже при частичном изменении данных.
Посмотрим на состояние файла лога (.ldf). При полной модели восстановления (Full Recovery Model) без регулярного бэкапа журнала транзакций файл лога разрастается, и SQL Server тратит ресурсы на управление огромным списком транзакций.
Решение: Если вам не нужна возможность восстановления базы на любую секунду времени, переведем базу в простую модель восстановления (Simple) и выполним сжатие (Shrink) лога. Это существенно снизит нагрузку на дисковую подсистему при массовой записи данных.
Рассмотрим специфику самой конфигурации «Управление торговлей». Проблема может крыться в неоптимальном запросе к партиям. В типовых решениях тех лет запрос по остаткам партий в цикле может работать медленно из-за особенностей построения временных таблиц в 1С. Решение: Программистам рекомендуется пересмотреть механизм формирования движений. Вместо обращения к итогам в цикле по каждой строке, следует выносить расчеты в пакетные запросы. Рассмотрим пример структуры эффективного кода:
// Вместо запроса в цикле по каждой строке
Для Каждого Строка Из Товары Цикл
Результат = ПолучитьОстаткиПартий(Строка.Номенклатура);
КонецЦикла;
// Используем выгрузку данных документа во временную таблицу и один запрос
Запрос.Текст = "ВЫБРАТЬ * ПОМЕСТИТЬ ВтТовары ИЗ &ТаблицаТоваров;
|ВЫБРАТЬ Партии.Номенклатура, Партии.КоличествоОстаток
|ИЗ РегистрНакопления.ПартииТоваровНаСкладах.Остатки( ,
|Номенклатура В (ВЫБРАТЬ Номенклатура ИЗ ВтТовары)) КАК Партии";
В регистрах накопления 1С существует режим «Разделить итоги». Он помогает при высокой параллельности (когда 50 человек одновременно бьют чеки), но при монопольном перепроведении может замедлять чтение данных, так как SQL вынужден суммировать данные из основной таблицы и таблицы разделителей.
Решение: Перед началом глобального перепроведения можно временно отключить режим разделения итогов для наиболее нагруженных регистров (ПартииТоваров, Продажи, ТоварыНаСкладах) и выполнить полный пересчет итогов. Это «схлопнет» записи и ускорит чтение.
sp_updatestats каждые 2–4 часа.MAXDOP = 1.TempDB на быстрый диск и нарезать на файлы..mdf, .ldf и .ndf в исключения антивируса.Lock Pages in Memory в политиках Windows.Соблюдение этих рекомендаций позволит избежать деградации производительности и обеспечит стабильную скорость перепроведения документов на протяжении всей операции.