Почему после обновления 1С долго проводятся документы и как это исправить?

Ситуация, когда после обновления конфигурации или манипуляций с базой данных (например, загрузки из DT-файла) проведение документов начинает занимать неоправданно много времени, знакома многим администраторам и разработчикам 1С. Рассмотрим, как системно подойти к поиску причины этого замедления и что именно нужно предпринять для исправления ситуации.

Шаг 1: Проведение замера производительности

Первое правило диагностики любых «тормозов» в системе — не гадать, а измерять. Прежде чем перенастраивать СУБД PostgreSQL или вносить изменения в код, необходимо точно понять, на каком этапе выполнения кода теряется время.

Для этого воспользуемся встроенным инструментом платформы — Замером производительности:

1. Откройте конфигуратор в режиме отладки.
2. Перейдите в меню Отладка -> Замер производительности.
3. Нажмите кнопку Включить.
4. В режиме «1С:Предприятие» выполните проведение проблемного документа «Реализация ТМЗ и услуг».
5. Вернитесь в конфигуратор, остановите замер и откройте его результаты.

Анализируя полученный отчет, мы сможем увидеть, какие именно модули, процедуры или запросы занимают наибольшее время (процент от общего времени выполнения). Если основная нагрузка приходится на Запрос к базе данных, значит, проблема кроется в взаимодействии 1С с PostgreSQL.

Шаг 2: Анализ взаимодействия с СУБД PostgreSQL

При использовании PostgreSQL критически важным фактором является актуальность статистики оптимизатора запросов. После обновления конфигурации структура таблиц меняется, добавляются новые поля, а объемы данных растут. Если статистика устарела, PostgreSQL может выбирать неэффективные планы выполнения запросов.

Рассмотрим, что нужно сделать для нормализации работы:

• Обновление статистики: Убедитесь, что регламентные задачи по обслуживанию базы данных выполняются корректно. В PostgreSQL важно настроить autovacuum, чтобы табличная статистика всегда оставалась актуальной.
• Реиндексация таблиц: После загрузки базы из DT-файла, индексы могут быть фрагментированы. Выполните полную реиндексацию таблиц базы данных средствами PostgreSQL. Не полагайтесь только на стандартное «Тестирование и исправление» из 1С, так как глубокая перестройка индексов на уровне СУБД работает эффективнее.
• Анализ блокировок: Иногда документ «висит» не из-за тяжелых расчетов, а из-за того, что он ожидает освобождения ресурса другими сеансами или регламентными заданиями. Используйте консоль администрирования серверов 1С для мониторинга активных блокировок в момент проведения документа.

Шаг 3: Глубокая диагностика через Технологический журнал

Если замер производительности показал, что проведение упирается в «длинный» SQL-запрос, пришло время использовать Технологический журнал. Это мощный инструмент, который позволяет зафиксировать запрос, превышающий пороговое значение времени выполнения.

Настройте конфигурационный файл logcfg.xml следующим образом:

<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\Logs" history="24">
    <event>
      <eq property="Name" value="DBPOSTGRS"/>
    </event>
    <property name="Duration"/>
    <property name="Sql"/>
  </log>
</config>
</config>

Установив фильтр, например, на Duration > 5000000 (5 секунд), вы получите в логах чистый текст SQL-запроса. Получив такой запрос, вы сможете выполнить его непосредственно в консоли управления PostgreSQL с использованием команды EXPLAIN ANALYZE. Это покажет, как именно база данных обрабатывает запрос: использует ли она Index Scan или же прибегает к «тяжелому» Seq Scan (полному сканированию таблицы).

Заключение: чек-лист действий

Чтобы окончательно решить проблему медленного проведения, придерживайтесь этого плана:

1. Выполните Замер производительности для выявления узкого места в коде.
2. Если тормозит запрос, проанализируйте план выполнения через EXPLAIN ANALYZE в СУБД.
3. Убедитесь в актуальности статистики PostgreSQL.
4. Проверьте наличие конкурентных блокировок, которые могут замедлять транзакцию.
5. При необходимости добавьте недостающие индексы в конфигураторе, если анализ плана запроса показывает их отсутствие для критически важных полей.

Помните, что обновление версии 3.0.35.6 часто сопровождается изменением логики учета (например, НДС или себестоимости), что само по себе требует больше ресурсов. Иногда требуется оптимизация не только базы, но и самой логики проведения документа в новых условиях учета.