← На главную

При росте объема информационной базы 1С:Управление торговлей 10.3 до 100 Гб и более стандартные операции (проведение документов РеализацияТоваровУслуг, ОтчетОРозничныхПродажах, ВозвратТоваровОтПокупателя) начинают выполняться со значительными задержками. Замедление связано с накоплением исторических данных, разрастанием таблиц итогов регистров накопления, неоптимальными запросами к партиям и очередями блокировок в СУБД. Разберем комплекс мер, позволяющих ускорить работу системы как на уровне конфигурации 1С, так и на уровне настроек MS SQL Server.

1. Диагностика узких мест и анализ таблиц базы данных

Прежде чем приступать к изменениям, выясним точную причину замедления. Размер базы сам по себе не определяет скорость проведения: ключевую роль играет распределение данных по таблицам и состояние индексов.

1. Замер производительности в конфигураторе: запустим отладчик с замером производительности при проведении проблемного документа. Проанализируем, на каких именно строках кода тратится больше всего времени — при расчете остатков, списании партий или выполнении проверок.
2. Анализ размеров таблиц в СУБД: определим, какие таблицы занимают основной объем. В конфигурациях линейки УТ 10.3 основную нагрузку обычно создают таблицы движений и итогов регистров ПартииТоваровНаСкладах, ТоварыНаСкладах, ЗаказыПокупателей и ВзаиморасчетыСКонтрагентами.
3. Проверка дат документов: убедимся, что в базе отсутствуют ошибочные документы с датами ранее даты ввода начальных остатков или документы из далекого будущего, так как они вызывают разрастание таблицы итогов вперед по временной шкале.

2. Оптимизация партионного учета и незакрытых остатков

Одной из главных причин медленного проведения документов списания является расчет себестоимости и контроль остатков в режиме онлайн.

1. Отключение онлайн-списания партий: если в настройках параметров учета включено списание партий при проведении документов, каждый документ пытается рассчитать себестоимость по алгоритму ФИФО/по средней, блокируя партионные таблицы. Переведем списание партий в регламентный режим: проведение документов будет фиксировать только количественные движения, а суммовая оценка и партии будут формироваться обработкой ПроведениеПоПартиям в фоновом режиме или во внерабочее время.
2. Очистка незакрытых ресурсов в регистрах («хвостов»): если по заказам или взаиморасчетам висят копеечные или единичные незакрытые остатки с прошлых лет, таблица итогов постоянно пересчитывает эти записи. Обработаем старые заказы покупателей и закроем нулевые или зависшие движения, чтобы разгрузить таблицы остатков.
3. Проверка индексов в метаданных: проверим свойства измерений в регистрах накопления. Измерения Номенклатура, Склад, ХарактеристикаНоменклатуры, а также реквизиты документов оприходования должны иметь установленное свойство индексации.

3. Свертка информационной базы

Если база содержит историю за много лет, эффективным способом снижения нагрузки является свертка остатков на определенную дату. Рассмотрим процедуру корректного среза:

1. Фиксация остатков: сформируем документы ввода остатков (или документы ОприходованиеТоваров, КорректировкаДолга) на конец выбранного периода среза по всем ключевым регистрам.
2. Снятие с проведения и удаление старых документов: отменим проведение и удалим первичные документы за закрытый период. Если требуется сохранить аналитику прошлых продаж, движения по оборотному регистру Продажи можно сохранить без изменений, очистив только остаточные регистры (движения по складам, партиям, заказам и взаиморасчетам).
3. Проведение документов ввода остатков: проведем сформированные документы на дату среза и выполним сверку отчетов (например, Ведомость по товарам на складах) до и после процедуры.
4. Обслуживание после свертки: после удаления миллионов строк выполним реиндексацию и сжатие базы данных средствами СУБД для высвобождения дискового пространства и дефрагментации страниц.

4. Настройка регламентных операций в 1С и MS SQL Server

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

1. Смещение границы итогов: настроим регулярное выполнение регламентного задания по пересчету итогов на конец предыдущего месяца. Это минимизирует объем данных, считываемых из физической таблицы движений при расчете остатков в виртуальных таблицах.
2. План обслуживания MS SQL Server: настроим ежедневное обновление статистики (для высоконагруженных таблиц — с параметром WITH FULLSCAN) и регулярную реиндексацию (Rebuild/Reorganize Indexes). Это исключит формирование неоптимальных планов выполнения SQL-запросов.
3. Режим версионирования строк (RCSI): включим для базы данных параметры READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION. Это позволит читающим запросам не блокировать пишущие транзакции при проведении документов.
4. Оптимизация базы tempdb: вынесем файлы tempdb на быстрый SSD/NVMe-диск и разделим их на несколько файлов одинакового размера по количеству физических ядер сервера (до 8 файлов), чтобы устранить конкуренцию потоков за страницы распределения.

5. Оптимизация серверного окружения

Проанализируем параметры инфраструктуры, влияющие на скорость выполнения серверных вызовов:

1. Временные файлы сервера 1С: перенесем каталог временных файлов пользователя, под которым запущена служба ragent, на быстрый твердотельный накопитель.
2. Схема электропитания: убедимся, что на сервере 1С и сервере СУБД установлена схема электропитания «Высокая производительность» (High Performance), а в BIOS/UEFI отключены энергосберегающие режимы процессора (C-States), чтобы ядра не сбрасывали тактовую частоту при межимпульсной нагрузке.
3. Взаимодействие сервера 1С и СУБД: при размещении сервера 1С и MS SQL на одной физической машине настроим подключение через протокол Shared Memory, что устранит накладные расходы сетевого стека.