Администрирование · 10 мин
Почему 1С долго проводит документы и как это исправить
Разбираем, почему 1С долго проводит документы: блокировки, индексы, итоги, регламентные задания. Практические шаги диагностики и ускорения проведения.
Медленное проведение документов — одна из самых частых жалоб пользователей 1С. Документ, который раньше проводился за секунду, внезапно «зависает» на минуты, а при массовом перепроведении база становится практически неработоспособной. Причина почти никогда не бывает одна: обычно это комбинация проблем с блокировками, состоянием базы данных, настройками конфигурации и нагрузкой от фоновых процессов.
Важно понимать, что проведение документа — это не просто запись в журнал. В момент проведения 1С формирует движения по регистрам, пересчитывает итоги, контролирует остатки, выполняет обработчики событий и может запускать цепочку связанных операций. Чем больше регистров задействовано и чем больше данных в базе, тем дольше длится эта операция.
Материал поможет системно разобраться в причинах: от простых, которые видны любому администратору, до тех, что требуют анализа технологического журнала и планов запросов СУБД. Действуйте последовательно — большинство проблем выявляется на первых этапах диагностики.
Какие симптомы указывают на конкретную причину
Прежде чем что-то менять, зафиксируйте характер проблемы. Если документы проводятся медленно у всех пользователей и в любое время — вероятнее всего, дело в состоянии базы или сервера. Если проведение «тормозит» только в часы активной работы — почти наверняка виноваты блокировки. Если медленно проводятся только определенные виды документов — проблема в логике их проведения или в связанных регистрах.
Полезно измерить время проведения одного и того же документа в монопольном режиме и в обычной работе. Разница в разы указывает на конкуренцию за ресурсы и взаимные блокировки. Отсутствие разницы означает, что операция сама по себе тяжелая, и нужно искать причину в структуре данных или коде.
Проверьте итоги регистров, индексы, нагрузку на СУБД
Смотрите список активных сеансов и блокировок в консоли кластера
Замерьте время по регистрам, проверьте запросы в модуле
Проверьте, завершились ли отложенные обработчики обновления
Блокировки: главная причина в многопользовательском режиме
Когда несколько пользователей одновременно проводят документы, затрагивающие одни и те же регистры и движения, 1С и СУБД устанавливают блокировки. Один сеанс ждёт освобождения ресурса другим — и проведение растягивается. Особенно заметно это при контроле остатков по складу: документы по одному складу фактически выстраиваются в очередь.
Посмотреть текущие блокировки можно в консоли кластера серверов 1С (раздел «Сеансы» и «Блокировки») или средствами СУБД — например, через представления активности в MS SQL Server. Если видите, что сеансы массово ждут друг друга, это подтверждение диагноза.
Что можно сделать на практике: включить управляемый режим блокировок (если конфигурация ещё использует автоматический), сократить время транзакций проведения, разнести массовые перепроведения на нерабочее время. В типовых конфигурациях также помогает включение раздельного контроля остатков и отказ от проведения «внакидку» большими пачками в разгар рабочего дня.
Состояние итогов и регистров
Регистры накопления и сведений со временем разрастаются, и операции с ними замедляются. Ключевой фактор для скорости проведения — состояние итогов регистров накопления. Если итоги отключены или «отодвинуты» далеко назад, каждый запрос к остаткам вынужден читать огромный массив движений вместо готовых агрегированных значений.
Проверить и исправить ситуацию можно через «Администрирование → Обслуживание → Управление итогами» (в типовых конфигурациях) или через соответствующие методы встроенного языка. Рекомендуется держать итоги рассчитанными по текущий период, а при массовом перепроведении старых документов — временно сдвигать границу итогов и возвращать её после завершения.
Отдельная тема — фрагментация индексов и устаревшая статистика на стороне СУБД. После длительной работы индексы таблиц регистров фрагментируются, и запросы начинают выполняться медленнее. Регулярная реиндексация и обновление статистики — стандартная часть регламентного обслуживания базы, её отсутствие почти гарантированно приводит к деградации скорости.
- 1Проверьте текущую границу рассчитанных итогов по основным регистрам накопления
- 2При отставании — выполните расчёт итогов по текущий период в нерабочее время
- 3Запустите реиндексацию таблиц базы средствами СУБД
- 4Обновите статистику на стороне СУБД
- 5Повторно замерьте время проведения типового документа и сравните с исходным значением
Нагрузка от конфигурации и доработок
Нетиповые доработки — частый источник проблем. Подписки на события «При проведении», обращения к внешним системам прямо в транзакции проведения, запросы в цикле, расчёт себестоимости «на лету» — всё это удлиняет транзакцию и усиливает блокировки. Даже одна неудачная доработка может замедлить проведение в разы.
Найдите узкое место замером: включите технологический журнал с фильтром по длительным событиям DBMSSQL/DBPOSTGRS и SDBL, либо используйте замер производительности в конфигураторе («Отладка → Замер производительности»). Замер покажет, какие строки кода и запросы занимают основное время.
Также проверьте, не выполняются ли в момент проведения регламентные и фоновые задания: обмены данными, расчёт себестоимости, отложенное проведение, полнотекстовое индексирование. Эти процессы конкурируют за ресурсы сервера и могут держать блокировки на тех же таблицах.
Сервер, СУБД и инфраструктура
Иногда конфигурация ни при чём: сервер просто не справляется. Типичные признаки инфраструктурной проблемы — постоянно высокая загрузка дисковой подсистемы, нехватка оперативной памяти (СУБД вытесняет данные из кэша), медленная сеть между сервером 1С и сервером СУБД, антивирус, проверяющий файлы базы в реальном времени.
Проверьте базовые метрики: загрузку CPU, очередь диска, свободную память на обоих серверах. Убедитесь, что каталоги базы данных и журнала транзакций исключены из проверки антивируса, а сервер 1С и СУБД расположены в одном сегменте сети. Для файлового режима работы дополнительно критична скорость диска и сети у клиентских машин — файловый вариант принципиально медленнее при росте базы и числа пользователей.
Как выбрать действие
Безопасный порядок диагностики
Работайте от простого к сложному и фиксируйте результат каждого шага. Без замеров «до» и «после» невозможно понять, помогло ли действие. Все изменения, затрагивающие конфигурацию или СУБД, сначала проверяйте на копии базы.
Ориентировочная последовательность: замер времени проведения в монопольном и обычном режиме → анализ блокировок → проверка итогов → регламентное обслуживание СУБД → замер производительности кода → анализ планов запросов. Если на каком-то шаге время нормализовалось, дальнейшие шаги можно не выполнять.
Как проверить результат
Сопоставимо со временем в монопольном режиме и не растёт в часы пик
В часы пик время растёт в разы — блокировки не устранены
Ожидания кратковременны и не выстраиваются в цепочки
Длинные цепочки ожиданий, сеансы висят минутами
Завершаются в отведённое окно без ошибок
Задания накладываются друг на друга и на рабочую активность
Часто задаваемые вопросы
Почему документ проводится быстро ночью, но медленно днём?
Почти наверняка дело в блокировках и конкуренции за ресурсы сервера. Днём работают пользователи и фоновые задания, которые удерживают блокировки на тех же регистрах. Проверьте список активных сеансов и перенесите тяжёлые регламентные задания на нерабочее время.
Поможет ли тестирование и исправление базы?
Тестирование и исправление устраняет логические и физические повреждения данных, но почти не влияет на скорость проведения в исправной базе. Если проблема в блокировках, итогах или коде, оно не поможет. Используйте его только при подозрении на повреждение данных и обязательно с резервной копией.
Можно ли ускорить проведение, отключив контроль остатков?
Технически да, проведение станет быстрее, но вы потеряете гарантию корректности остатков: появятся отрицательные значения, которые потом придётся разбирать вручную. Такой шаг оправдан только как временная мера с последующим восстановлением контроля.
Влияет ли размер базы на скорость проведения?
Да, но опосредованно: растут таблицы регистров, удлиняются запросы, увеличивается время обслуживания индексов. Регулярный расчёт итогов, реиндексация и свёртка старых периодов заметно смягчают эффект роста базы.
Что делать, если медленное проведение началось сразу после обновления конфигурации?
Сначала проверьте, завершились ли отложенные обработчики обновления — пока они работают, база находится под дополнительной нагрузкой. Если обработчики завершены, а проблема осталась, сравните модули проведения с предыдущей версией и сделайте замер производительности, чтобы найти новый «тяжёлый» код.
Что важно запомнить
Медленное проведение документов — почти всегда следствие блокировок, нерассчитанных итогов, тяжёлого кода в модулях проведения или перегруженного сервера. Начинайте с замеров и анализа блокировок, проводите регламентное обслуживание СУБД регулярно, а все изменения проверяйте на копии базы.