Администрирование · 13 мин
Как ускорить проведение документов в 1С
Разбираем, почему документы в 1С проводятся медленно, и как ускорить проведение: настройка СУБД, индексы, итоги, блокировки, регламентные задания и типовые ошибки.
Медленное проведение документов — одна из самых частых жалоб пользователей 1С. Документ «Реализация товаров» проводится 30 секунд вместо двух, групповое перепроведение за месяц занимает ночь, а в часы пик база фактически встаёт. При этом причина редко одна: обычно медленное проведение — это комбинация проблем на уровне СУБД, конфигурации, регистров и настроек самой платформы.
Ускорение проведения документов в 1С начинается не с «тюнинга всего подряд», а с диагностики: нужно понять, где именно теряется время. Это может быть ожидание на блокировках, отсутствие индексов по измерениям регистров, нерассчитанные итоги, тяжёлые доработки в обработчиках проведения или просто устаревшая статистика в базе данных. Каждая причина требует своего решения, и без диагностики любые изменения — это работа вслепую.
В статье разобраны прикладные методы, которые применимы к типовым конфигурациям (УТ, ERP, БП, КА) на клиент-серверной архитектуре с MS SQL Server или PostgreSQL. Часть приёмов доступна администратору без изменения конфигурации, часть требует доработки кода и тестирования на копии базы.
Как найти, где именно теряется время при проведении
Первый шаг — воспроизвести проблему и замерить. Возьмите конкретный «тяжёлый» документ и проведите его на копии базы с включённым технологическим журналом (ТЖ) на сервере 1С. В ТЖ настраивается сбор событий DBMSSQL (или DBPOSTGRS) и TLOCK — так вы увидите, какие запросы выполняются дольше всего и где возникают ожидания на блокировках.
Второй инструмент — встроенный замер производительности (в конфигурациях на БСП: «Администрирование» → «Обслуживание» → «Оценка производительности»). Он покажет, какие участки кода обработчика проведения занимают больше всего времени. Если типовой замер недоступен, используйте консоль кода с замерами через ТекущаяУниверсальнаяДатаВМиллисекундах() вокруг подозрительных участков.
Третий источник данных — средства самой СУБД. Для MS SQL это план выполнения запроса и динамические представления (dm_exec_query_stats), для PostgreSQL — pg_stat_statements. Если самый долгий запрос — чтение остатков регистра без подходящего индекса, это видно сразу по плану: сканирование таблицы вместо поиска по индексу.
- 1Воспроизведите медленное проведение на копии базы и зафиксируйте время
- 2Включите технологический журнал с событиями DBMSSQL и TLOCK, повторите проведение
- 3Найдите самые длительные запросы и ожидания на блокировках
- 4Снимите план выполнения проблемного запроса в СУБД
- 5Зафиксируйте вывод: блокировки, индексы, итоги или код — и переходите к соответствующему разделу
Блокировки: главная причина «зависаний» при параллельной работе
Если документы проводятся медленно только при одновременной работе нескольких пользователей, а в монопольном режиме всё быстро — проблема в блокировках. Типовая картина: проведение реализаций упирается в контроль остатков по регистру «Товары на складах», и пользователи ждут друг друга по записи.
Проверьте, что в свойствах конфигурации включён управляемый режим блокировки данных («Режим управления блокировкой данных» — «Управляемый» или «Управляемый и автоматический»). Автоматический режим на больших базах даёт избыточные табличные блокировки. Для регистров накопления также проверьте свойство «Режим разделения итогов» — о нём ниже.
На уровне СУБД для MS SQL критично включить версионирование: параметры базы ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT. Без них чтение блокируется записями, и даже отчёты могут мешать проведению. Это стандартная рекомендация для 1С, но на базах, созданных давно или восстановленных из копий, настройка часто отключена.
Итоги регистров и разделение итогов
Регистры накопления хранят предрассчитанные итоги, и механизм их обновления сильно влияет на скорость проведения. Если регистр работает в старом режиме без разделения итогов, запись движений обновляет таблицу итогов, что при параллельном проведении даёт взаимные блокировки даже по разным товарам.
Решение — включить разделение итогов для тяжёлых регистров накопления (свойство регистра «Режим разделения итогов»). В этом режиме итоги пишутся с разделителем по периодам, что снимает конкуренцию между сеансами. В современных типовых конфигурациях это включено по умолчанию, но в старых или самописных — часто нет.
Отдельно проверьте актуальность итогов: если итоги «отключены» на прошлые периоды или рассчитаны не до текущей даты, запросы остатков начинают читать вместо таблицы итогов всю таблицу движений — и проведение, и отчёты резко замедляются. Состояние итогов видно в режиме предприятия через функции технического специалиста («Управление итогами») или через методы встроенного языка ПолучитьМаксимальныйПериодРассчитанныхИтогов.
Индексы и состояние базы данных
СУБД со временем «забывает», как ей эффективно выполнять запросы: статистика устаревает, индексы фрагментируются. Регламентное обслуживание базы — обновление статистики и перестройка/реорганизация индексов — должно выполняться регулярно, желательно еженедельно в нерабочее время. На практике одно обновление статистики нередко ускоряет проблемный запрос в разы без каких-либо других мер.
Если в конфигурации есть доработки, проверьте, что запросы в обработчиках проведения используют поля, по которым есть индексы. Классическая ошибка — отбор по реквизиту документа или по неиндексированной комбинации измерений регистра. Индексы по реквизитам включаются в конфигураторе (свойство «Индексировать»), а для регистров — через индексирование измерений и реквизитов.
Также убедитесь, что в запросах нет соединений с виртуальными таблицами без отборов и обращений к ним «в лоб» по большим регистрам. Виртуальная таблица остатков без условия по номенклатуре и складу читает итоги целиком — правильный запрос всегда передаёт отборы параметрами виртуальной таблицы.
Проверьте режим управления блокировкой, разделение итогов, READ_COMMITTED_SNAPSHOT
Смотрите план запроса, индексы, статистику, замер кода обработчика
Проверьте фрагментацию индексов, актуальность статистики, рост таблиц
Сравните время проведения на типовой и доработанной конфигурации
Оптимизация кода проведения
Если диагностика показала, что время уходит на серверный код, а не на ожидания, работа идёт с обработчиком проведения. Самые частые источники тормозов — запросы в цикле по строкам табличной части, чтение остатков отдельно по каждой строке и лишние обращения к базе в подписках на события.
Правило простое: один запрос к базе вместо N запросов в цикле. Остатки по всем строкам документа получаются одним запросом к виртуальной таблице с отбором по списку номенклатуры из табличной части. То же касается цен, штрихкодов, данных договоров — всё выбирается пакетно и дальше обрабатывается в памяти.
Проверьте подписки на события «ОбработкаПроведения» и «ПриЗаписи»: в доработанных конфигурациях там нередко живут рассылки уведомлений, обмены с внешними системами и пересчёты, которые выполняются синхронно в транзакции проведения. Всё, что не обязано быть частью транзакции, нужно выносить в фоновые задания или отложенную обработку.
Настройки документов и последовательностей
Скорость проведения зависит и от архитектурных настроек. Проверьте длину номера документов: избыточная длина номера (например, 20 символов с префиксами) замедляет работу механизма нумерации и увеличивает индексы. Для большинства случаев достаточно 11 символов.
Если документ входит в последовательности, их восстановление при перепроведении может быть дорогим. Убедитесь, что границы последовательностей актуальны, а регламентное задание восстановления (если используется отложенное проведение) работает штатно и не «догоняет» огромный хвост документов в рабочее время.
Для конфигураций, где это предусмотрено (УТ 11, ERP, КА), рассмотрите отложенное проведение: документ записывается и проводится оперативно, а формирование проводок и части движений выполняется регламентным заданием. Это существенно ускоряет интерактивную работу пользователей, но требует контроля за очередью отложенного проведения.
Сравнение вариантов
Актуальные остатки сразу, но контроль остатков и движения выполняются синхронно — медленнее при высокой нагрузке
Быстрая запись для пользователя, движения формирует регламентное задание; требует мониторинга очереди и не подходит там, где нужен мгновенный контроль остатков
Максимально быстрое проведение, но возможны отрицательные остатки; допустимо только при внешнем контроле или в закрытых периодах
Аппаратный уровень и инфраструктура
Если на уровне кода и СУБД всё оптимизировано, а проведение всё равно медленное, смотрите на железо. Для сервера СУБД критичны быстрые диски (SSD/NVMe) для файлов данных и журнала транзакций, достаточный объём оперативной памяти и корректное ограничение памяти SQL Server, чтобы он не отбирал ресурсы у ОС.
Разнесение сервера 1С и СУБД по разным машинам с быстрой сетью между ними — стандартная схема для нагруженных систем. На одной машине они конкурируют за память и процессор. Также проверьте план электропитания сервера: режим экономии энергии заметно снижает производительность процессора под нагрузкой.
Файловый режим работы — отдельный случай: в нём возможности оптимизации ограничены. Если база выросла и документы проводятся медленно именно в файловом варианте, переход на клиент-серверную архитектуру даст больший эффект, чем любые точечные настройки.
Как выбрать действие
Проверка результата и регламентная работа
После каждого изменения измеряйте эффект на том же документе и том же наборе данных: проведение до и после, фиксация времени. Без повторного замера невозможно понять, что именно помогло. Удобно вести простую таблицу замеров по каждому изменению.
Закрепите результат регламентом: еженедельное обновление статистики и обслуживание индексов, мониторинг длительных запросов и блокировок, контроль состояния итогов и очередей отложенного проведения. Производительность деградирует постепенно, и без регламентных процедур проблема вернётся через несколько месяцев.
Как проверить результат
Стабильно снизилось на одинаковых данных и не зависит от числа пользователей
Ускорилось только в монопольном режиме — блокировки не устранены
Нет запросов длиннее секунды и ожиданий TLOCK при типовой операции
Длительные запросы или блокировки остались — причина не найдена
Итоги рассчитаны до актуального периода, разделение итогов включено
Итоги отстают или отключены — запросы читают таблицу движений
Частые вопросы
Поможет ли ускорить проведение простое увеличение памяти сервера?
Только если проблема действительно в нехватке памяти: это видно по активному использованию файла подкачки и постоянному чтению данных с диска. Если узкое место — блокировки или неоптимальные запросы, добавление памяти эффекта не даст. Сначала замер, потом железо.
Безопасно ли отключать контроль остатков для ускорения?
Технически да, это убирает чтение остатков и часть блокировок при проведении. Но система перестанет защищать от отгрузки «в минус», поэтому приём оправдан только при внешнем контроле остатков или для закрытых периодов. Решение принимайте осознанно и фиксируйте его в регламенте.
Почему перепроведение документов за период занимает часы?
Групповое перепроведение выполняет полный цикл проведения каждого документа, включая восстановление последовательностей и пересчёт зависимых движений. Ускорить можно, выполняя его в нерабочее время, предварительно обновив статистику, отключив неиспользуемые регистры в движениях и убедившись, что итоги рассчитаны.
Влияет ли версия платформы 1С на скорость проведения?
Да, в новых релизах платформы регулярно оптимизируются механизмы записи движений, работы с итогами и блокировками. Перед обновлением проверьте совместимость конфигурации и протестируйте на копии — само по себе обновление не всегда даёт прирост, но на старых версиях часть современных оптимизаций недоступна.
Что делать, если медленно проводится только один вид документов?
Это почти всегда локальная проблема: тяжёлый обработчик проведения, доработки в подписках именно этого вида или запрос к регистру без подходящего индекса. Снимите замер производительности именно на этом документе и сравните с похожим быстрым видом — разница укажет на источник.
Нужно ли ускорять проведение, если база файловая?
Базовые приёмы (актуальные итоги, оптимизация кода, отключение лишних движений) работают и в файловом режиме. Но файловая СУБД не имеет управляемых блокировок на уровне записей и версионирования, поэтому при росте числа пользователей переход на клиент-серверный вариант эффективнее любых точечных настроек.