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