Диагностика производительности 1С: что измерять и как проверить результат

Чтобы разобраться с медленной 1С, нужно связать ожидание пользователя с конкретной операцией и условиями её выполнения. Ниже — порядок подготовки данных и проверки результата, который можно обсудить с администратором или разработчиком.

Автор: Александр Усольцев. Опубликовано 2 ноября 2026.

Начните с одной воспроизводимой операции

Вместо общего «всё тормозит» выберите действие, которое мешает работе: открытие формы, проведение документа, построение отчёта или закрытие периода. Запишите, что нажимает пользователь и какой результат ожидает. Укажите, проблема возникает у всех или только на отдельном рабочем месте.

Если задержки происходят нерегулярно, сохраните несколько точных отметок времени. Они помогут сопоставить жалобу с журналами и нагрузкой. Совпадение с обновлением или обменом — исходная гипотеза, которую ещё предстоит проверить.

Что подготовить до диагностики

Конфигурация и её релиз, версия платформы, расширения и существенные доработки.
Вариант работы: файловая база, клиент-серверная система или облачный сервис; для серверной базы — СУБД и её версия.
Конкретная медленная операция, последовательность действий, параметры отчёта или объём документов.
Дата и время задержки с часовым поясом, её длительность, частота повторения и текст ошибки, если он появился.
Число одновременно работающих пользователей и фоновые задания или обмены в этот момент.
Когда проблема началась и какие обновления, настройки, доработки или изменения нагрузки ей предшествовали.

Для первого обращения достаточно описания и обезличенного снимка ошибки. Доступы, копии базы и журналы передавайте только по согласованному защищённому каналу: они могут содержать сведения о клиентах и работе компании.

Как получить сопоставимые замеры

Запишите время от начала действия до готового результата. Повторите тот же сценарий несколько раз и сохраните отдельные результаты, а не только самый удачный. Отмечайте первый запуск отдельно от повторных: условия могут отличаться из-за кэша и подготовительных операций.

Для сравнения до и после нужны одинаковые параметры, сопоставимый объём данных и нагрузка. В тестовой базе не запускайте реальные отправки, оплаты и внешние обмены. Если условия различаются, укажите это в выводах.

В документации 1С:EDT описаны замеры участков кода и сравнение результатов. Замер в режиме отладки и обычное время ожидания пользователя — разные наблюдения; вывод об улучшении проверяйте на рабочем сценарии.

Какие данные сопоставляет специалист

Инфраструктура: процессор, память, задержки диска и сеть в момент медленной операции.
Приложение: серверные вызовы, затратные участки кода, технологический журнал и фоновые задания.
СУБД: длительные запросы, ожидания, планы выполнения и обслуживание базы — если используется клиент-серверный вариант.

Центр управления производительностью 1С помогает собирать показатели и разбирать узкие места клиент-серверной системы. Выбор инструментов зависит от размещения базы и доступных прав; устанавливать весь набор для каждой задачи не требуется.

Для PostgreSQL доступны данные об активности и статистике, но их интерпретируют с учётом версии и настроек. Одна высокая загрузка процессора или один долгий запрос ещё не объясняют все задержки.

Если зависает проведение документов или закрытие периода

Зафиксируйте документ или этап закрытия, момент начала, условия запуска и сообщение об ошибке. Не публикуйте содержимое учётных документов.
Проверьте, операция действительно завершилась с ошибкой или продолжает выполняться. Повторные клики могут создать дополнительную нагрузку и усложнить разбор.
Администратор сопоставляет сеанс 1С с запросами СУБД и ожиданиями. Нужно различить длительное выполнение, ожидание блокировки и взаимоблокировку.
Для конфликтующих операций разбирают участников ожидания, границы транзакций, порядок обращения к данным и пересечение с заданиями. Для медленного запроса — план и объём обработки.
Исправление проверяют на сопоставимом сценарии: проведение должно завершаться корректно, а не просто быстрее показывать сообщение.

Документация PostgreSQL описывает режимы блокировок и взаимоблокировки. Механизмы СУБД и управляемые блокировки 1С нужно анализировать с учётом конкретной системы. Не завершайте сеансы и не меняйте режим блокировок без оценки влияния на текущие операции.

Пример из практики: после перехода на Бухгалтерию КОРП работе мешали взаимоблокировки и неоптимальные планы запросов. После исправлений групповое проведение и закрытие периода перестали зависать. Это отдельный кейс, а не готовый диагноз для любой базы.

Что должно остаться после обследования

Сценарий и исходные замеры с описанием условий.
Наблюдения, подтверждённые причины и гипотезы, которые ещё требуют проверки.
План изменений: кто выполняет, в каком порядке и как проверяется корректность.
Резервная копия и согласованный порядок возврата перед изменениями.
Повторные замеры и вывод: что улучшилось, какие ограничения остались и что контролировать дальше.

Не меняйте одновременно всё: иначе будет трудно понять, что повлияло на результат. Диагностика может закончиться рекомендацией по коду, расписанию, инфраструктуре или обращением к провайдеру; покупка сервера и смена СУБД выбираются по фактам.

Материалы и помощь

Почему тормозит 1С — обзор возможных причин.
Ускорение 1С — состав услуги и порядок обращения.
Сопровождение 1С — обновления, доработки и регулярная поддержка.

Первичные источники

Возможности инструментов и доступ к ним зависят от версий и условий использования. Сверяйтесь с документацией вашей платформы и СУБД.