Ситуация, когда перепроведение документов за несколько месяцев затягивается на дни, является классической проблемой для крупных баз 1С. Мы часто сталкиваемся с тем, что даже после обновления дисковой подсистемы на современные SSD, общая скорость проведения растет незначительно. В этой статье мы подробно разберем, почему «железо» не всегда спасает ситуацию, проанализируем архитектурные особенности 1С и SQL Server, а также разработаем план действий для ускорения массовых операций.
Разберем типичную ошибку при оценке серверных ресурсов. Многие полагают, что наличие двух многоядерных процессоров (например, Xeon X5650) гарантирует высокую скорость. Однако архитектура 1С такова, что процесс проведения одного конкретного документа выполняется последовательно в одном потоке. Это означает, что в конкретный момент времени вся мощь сервера для одной транзакции сжимается до производительности одного ядра.
Проанализируем ситуацию: процессоры старых поколений имеют низкую производительность на такт (IPC). Для 1С критически важна частота и современная архитектура ядра, а не их общее количество. Если в диспетчере задач вы видите общую загрузку процессора 5–10%, но при этом работа идет медленно, посмотрите на загрузку отдельных ядер. Скорее всего, одно ядро загружено на 100%, а остальные простаивают. Выясним причину: система уперлась в «потолок» производительности одного потока. Для ускорения таких задач требуются процессоры с высокой частотой (от 3.5 ГГц и выше).
Одной из самых тяжелых операций при проведении документа является пересчет итогов по регистрам. Когда мы проводим 300 000 документов за 4 месяца, система при записи каждого движения пытается актуализировать таблицы итогов. Рассмотрим эффективный метод ускорения этого процесса — управление итогами.
Перед запуском глобального перепроведения рекомендуется отключить использование итогов или сдвинуть период рассчитанных итогов на начало периода перепроведения. Это избавит SQL Server от необходимости обновлять миллионы записей в промежуточных таблицах итогов в режиме реального времени. По завершении процесса итоги рассчитываются один раз за весь период.
Пример кода для управления итогами через встроенный язык:
// Отключение итогов для регистра накопления
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Ложь);
// После проведения всех документов - включение и пересчет
РегистрыНакопления.Продажи.УстановитьИспользованиеИтогов(Истина);
РегистрыНакопления.Продажи.ПересчитатьИтоги();
Массовое перепроведение генерирует колоссальный объем записей в транзакционный лог базы данных (файл LDF). Если ваша база данных находится в модели восстановления Full, SQL Server будет дожидаться подтверждения записи каждой операции в лог, что создает огромные задержки.
Проанализируем шаги по оптимизации СУБД:
TempDB. При перепроведении 1С активно использует временные таблицы. TempDB должен располагаться на самом быстром SSD-накопителе в системе.TCP/IP в данном случае добавляет ненужный сетевой оверхед на тысячи мелких запросов.Часто внедренцы используют стандартные механизмы проведения, которые включают в себя массу проверок: контроль остатков, проверка прав доступа, заполнение связанных реквизитов. В ситуации, когда документы уже существуют в базе и их нужно просто «обновить», многие из этих проверок избыточны.
Мы можем программно ускорить проведение, установив свойство ОбменДанными.Загрузка в значение Истина. Это отключает большинство платформенных и программных проверок в процедурах ПередЗаписью и ПриЗаписи. Однако будьте осторожны: этот метод требует понимания того, не нарушится ли логика формирования движений.
ДокументОбъект = СсылкаНаДокумент.ПолучитьОбъект();
ДокументОбъект.ОбменДанными.Загрузка = Истина;
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);
Если последовательное проведение занимает слишком много времени, единственный путь — задействовать все ядра сервера. Разберем, как это сделать. Мы можем разбить массив из 300 000 документов на пакеты (например, по организациям или по типам документов) и запустить несколько фоновых заданий одновременно.
Важно помнить о блокировках: если документы из разных потоков будут пытаться изменить одни и те же данные (например, один и тот же склад в один и тот же момент времени), возникнут ожидания на блокировках, и скорость упадет. Идеально распараллеливаются документы, не имеющие общих аналитик (разные организации, разные группы товаров).
Пример структуры для запуска фонового задания:
ПараметрыЗадания = Новый Массив;
ПараметрыЗадания.Добавить(СписокДокументовДляПотока);
ФоновыеЗадания.Выполнить("МойМодуль.ПровестиПакетДокументов", ПараметрыЗадания);
Перед тем как ответить руководству «почему так долго», проанализируйте следующие пункты:
Подведем итог: скорость 1.7 секунды на один документ (300 000 доков за 2 суток) — это вполне стандартный показатель для тяжелых, переписанных конфигураций. Для радикального ускорения необходимо переходить от последовательного штатного перепроведения к программному распараллеливанию с отключением итогов и избыточных проверок кода.