В процессе эксплуатации распределенных информационных баз (РИБ) системные администраторы и разработчики часто сталкиваются с парадоксальной ситуацией: в небольших торговых точках, где используется файловый вариант базы данных, закрытие смены и формирование документов происходит за считанные минуты. Однако в крупных узлах, переведенных на MS SQL Server для повышения стабильности и объема данных, та же самая операция может занимать 20–30 минут и более. При этом система визуально «зависает» на этапе записи движений в регистры.
В данной статье мы подробно разберем причины такого поведения системы на примере конфигурации «Управление торговым предприятием» (УТП), проанализируем влияние фоновых процессов и определим шаги по оптимизации серверной части для ускорения работы РМК (рабочего места кассира).
Рассмотрим стандартный процесс закрытия смены. В этот момент система выполняет несколько тяжелых транзакций: архивацию чеков ККМ и создание документа ОтчетОРозничныхПродажах. В SQL-версии базы данных любая запись в регистры накопления сопровождается пересчетом итогов и обновлением индексов таблиц. Если в файловой базе эти операции выполняются последовательно и монопольно, то в SQL-варианте в процесс могут вмешиваться параллельные задачи.
Проанализируем ситуацию, выявленную в ходе обсуждения: основная задержка происходит не из-за объема самих данных, а из-за возникновения «окна» между транзакциями, в которое вклиниваются регламентные операции платформы. Выясним, какие именно факторы превращают минутную операцию в получасовое ожидание.
Как показывает практика и анализ журнала регистрации, основной причиной «зависания» часто является фоновое задание Обновление индекса полнотекстового поиска. Рассмотрим подробнее, почему это критично именно для РИБ:
ОтчетОРозничныхПродажах, происходит массовая запись в таблицы базы данных. Это служит триггером для системы: она пытается «помочь» пользователю и запускает обновление индекса именно в этот момент.Поскольку 95% пользователей не используют механизм полнотекстового поиска в повседневной работе (предпочитая стандартный поиск в списках), самым эффективным решением будет его полное отключение. Разберем, как это сделать программно:
// Отключение использования полнотекстового поиска через встроенный язык
ПолнотекстовыйПоиск.УстановитьИспользованиеРазделения(Ложь);
ПолнотекстовыйПоиск.УстановитьИспользование(Ложь);
Также мы можем отключить это задание в обработке «Консоль регламентных заданий» или непосредственно в настройках программы (Сервис — Настройка параметров учета — Органайзер), сняв флаг «Использовать полнотекстовый поиск».
Проанализируем сетевое взаимодействие между сервером приложений 1С и MS SQL Server. Если оба сервера установлены на одной физической или виртуальной машине, использование протокола TCP/IP создает лишнюю нагрузку на сетевой стек, что замедляет передачу больших пакетов данных при записи в регистры.
Нам необходимо убедиться, что включен протокол Shared Memory (общая память). Это позволит процессам rphost.exe и sqlservr.exe обмениваться данными напрямую через оперативную память. Для этого:
SQL Server Network Configuration — Protocols for MSSQLSERVER.Shared Memory находится в состоянии Enabled.lpc:ИмяСервера.Одной из причин медленного проведения документов в 1С:УТП является некорректно установленный период рассчитанных итогов. Если в периферийной базе итоги рассчитаны на дату, значительно отстающую от текущей, SQL-сервер при проведении Отчета о розничных продажах будет вынужден динамически вычислять остатки, начиная с даты актуальности итогов до даты документа.
Выполним следующие действия для оптимизации:
Разберем важный параметр MAXDOP (Maximum Degree of Parallelism). По умолчанию SQL Server пытается распараллелить выполнение одного тяжелого запроса на все доступные ядра процессора. При проведении сложных документов 1С это часто приводит к возникновению взаимных блокировок типа LATCH_EX.
Рекомендуем выполнить следующие настройки в свойствах сервера SQL:
Max Degree of Parallelism в значение 1. Это заставит SQL выполнять каждый отдельный запрос в рамках одного потока, что исключает накладные расходы на синхронизацию потоков внутри одной транзакции 1С.Cost Threshold for Parallelism в значение 50 (вместо стандартных 5). Это позволит серверу распараллеливать только действительно огромные задачи, не трогая стандартные операции проведения.В отличие от файловой базы, SQL-база требует регулярного обновления статистики. План запроса (то, как SQL будет записывать данные в регистры) строится на основе статистических данных. Если они устарели после массовой загрузки данных из РИБ, SQL может выбрать неэффективный путь записи, что увеличит время закрытия смены в десятки раз.
Рассмотрим регламент, который должен выполняться в SQL-версии периферийной базы:
TempDB вынесена на быстрый диск (SSD) и разделена на несколько файлов (по количеству ядер процессора, но не более 8), так как при проведении документов 1С активно использует временные таблицы.Подводя итог, можно сказать, что «тормоза» на SQL в РИБ — это всегда следствие совокупности факторов. В первую очередь необходимо отключить полнотекстовый поиск, так как он создает непредсказуемую нагрузку в момент финализации смены. Во вторую очередь — проверить системные настройки Shared Memory и MAXDOP. Сочетание этих мер позволяет сократить время закрытия смены в 1С:УТП с 30 минут до исходных 1–2 минут, сопоставимых с файловым режимом работы.