Проблема медленного проведения документов в крупных базах данных 1С (объемом свыше 200 Гб) является классической для конфигураций «Комплексная автоматизация 1.1» и «УПП 1.3». Когда проведение ПоступлениеТоваровУслуг занимает более 10 минут, это сигнализирует о комплексе проблем: от неоптимальных настроек SQL-сервера до архитектурных особенностей самой конфигурации. Разберем пошагово, как продиагностировать систему и какие меры предпринять для ускорения работы.
Прежде чем менять настройки сервера, нам необходимо понять, на чем именно «спотыкается» система. Возможно, проблема не в SQL, а в конкретном куске кода или бесконечном цикле при расчете себестоимости. Для этого воспользуемся встроенным инструментом отладки.
Рассмотрим алгоритм действий для программиста:
РеализацияТоваровУслуг).ОбработкаПроведения.Проанализируем полученную таблицу. Нас интересуют колонки «Число вызовов» и «Общее время». Обычно «узкое место» — это запросы к регистрам накопления для получения остатков или расчет партий. Если мы видим, что одна строка кода выполняется 600 секунд, значит, проблема в тяжелом SQL-запросе или блокировках таблиц.
Если замер показал, что время уходит на выполнение запросов к СУБД, перейдем к настройке SQL Server. Для баз 1С объемом 236 Гб стандартные настройки «из коробки» не подходят. Проанализируем ключевые параметры:
1. Параметр Max Degree of Parallelism (MAXDOP)
Для систем 1С крайне рекомендуется установить MAXDOP = 1. Это запрещает серверу распараллеливать один запрос на несколько ядер процессора. Хотя это звучит контринтуитивно, на практике это избавляет от взаимных блокировок (deadlocks) и ожидания ресурсов при тяжелых операциях проведения.
2. Настройка файлов TempDB
База TempDB активно используется 1С для временных таблиц. Разделим TempDB на несколько файлов (рекомендуется 8 файлов или по количеству физических ядер процессора) одинакового размера. Это снизит конкуренцию за системные страницы распределения памяти (GAM, SGAM).
3. Авторасширение файлов (Autogrowth)
Посмотрим на настройки роста файлов базы и лога. Если установлено расширение «в процентах», на базе 236 Гб это приведет к огромным задержкам. Установим фиксированный размер расширения, например, 512 МБ или 1024 МБ. Это позволит SQL Server заранее выделять место, не прерывая транзакцию проведения документа на длительное время.
При активном вводе данных индексы таблиц регистров (например, РегистрНакопления.ПартииТоваровНаСкладах) фрагментируются. Если фрагментация превышает 30%, SQL Server тратит гораздо больше времени на чтение данных с диска. Выясним причину замедления через регламентные операции.
Необходимо настроить ежедневный план обслуживания (Maintenance Plan) в SQL Server Management Studio:
Для баз такого объема обновление статистики рекомендуется делать не один раз в сутки, а несколько (например, в обеденный перерыв и ночью), особенно для таблиц итогов регистров накопления.
В конфигурации «Комплексная автоматизация» основной «тормоз» при проведении — это механизм списания партий. Рассмотрим настройку учетной политики.
Если в настройках включена опция «Списывать партии при проведении документов», то при каждом поступлении или реализации система пытается рассчитать себестоимость в режиме реального времени. На базе в 236 Гб это создает колоссальную нагрузку.
Решение:
Отключите эту опцию в учетной политике. В этом случае документы будут проводиться мгновенно (только по количеству), а расчет себестоимости и движений по партиям будет выполнять регламентная обработка Проведение по партиям в конце дня или в периоды минимальной нагрузки. Это кардинально ускорит оперативную работу пользователей.
Иногда причина кроется в «расползании» итогов регистров. Выполним следующие действия в режиме Конфигуратора:
Важно помнить: на базе 236 Гб эти операции могут занять многие часы, поэтому выполнять их нужно строго в технологическое окно (выходные дни). Пересчет итогов позволяет 1С обращаться к актуальным агрегированным данным в SQL, что ускоряет получение остатков в запросах ОстаткиИОбороты.
Если проблема вызвана блокировками, мы можем использовать технологический журнал или программный код для анализа. Разберем пример того, как можно проверить наличие блокировок программно, хотя для SQL-версии эффективнее использовать SQL Profiler или стандартные отчеты в Management Studio (Activity Monitor).
Тем не менее, при доработке конфигурации важно следить за порядком обращения к объектам. Посмотрим на типичную ошибку: сначала блокируется справочник, потом регистр. Правильно делать наоборот или использовать режим управляемых блокировок.
// Пример установки управляемой блокировки для ускорения в режиме 8.2
ЭлементБлокировки = Блокировка.Добавить("РегистрНакопления.ТоварыНаСкладах");
ЭлементБлокировки.УстановитьЗначение("Склад", СкладОбъект);
ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;
Блокировка.Заблокировать();
Однако помните, что КА 1.1 изначально работает в режиме Автоматических блокировок. Перевод отдельных документов на управляемые блокировки требует серьезного изменения кода и свойств всей конфигурации.
Для ускорения проведения в вашем случае необходимо действовать в три этапа: сначала Замер производительности в 1С для локализации кода, затем настройка SQL (MAXDOP, TempDB, планы обслуживания) и в завершение — отказ от оперативного списания партий в пользу регламентного. Это позволит сократить время проведения с 10 минут до нескольких секунд.