Как узнать, что грузит 1С: пошаговая диагностика

Когда 1С «тормозит», пользователи обычно описывают проблему расплывчато: «всё висит», «документы долго проводятся», «отчёт открывается десять минут». Однако за одинаковыми симптомами стоят совершенно разные причины: перегруженный сервер СУБД, неоптимальный запрос в конкретном отчёте, антивирус на рабочем месте или фоновое регламентное задание, которое запустилось в разгар рабочего дня. Пока вы не определите, какой именно компонент создаёт нагрузку, любые попытки «ускорить» систему будут стрельбой вслепую.

Диагностика строится по принципу «от простого к сложному»: сначала смотрим, какой процесс потребляет ресурсы, затем определяем, какой сеанс и какая операция этот процесс породили, и только потом ищем конкретный запрос или фрагмент кода. Такой порядок исключает лишнюю работу: нет смысла разбирать запросы, если процессор сервера занят антивирусным сканированием.

Ниже описан практический маршрут диагностики, который подходит и для файловых баз, и для клиент-серверных установок на 1С:Предприятии 8.3 с MS SQL Server или PostgreSQL. Большинство шагов можно выполнить штатными средствами без покупки дополнительного ПО.

Шаг 1. Определите, где именно проявляется проблема

Первый вопрос диагностики: тормозит у всех пользователей или только у одного? Если медленно работает только один компьютер, а остальные работают нормально, искать проблему нужно на этом рабочем месте: загрузка процессора и диска, антивирус, сетевое подключение, устаревший клиент 1С. Если страдают все — проблема на сервере или в самой базе.

Второй вопрос: тормозит всё или конкретная операция? Если медленно открываются все формы и списки, вероятны системные причины — нехватка оперативной памяти, перегруженный диск, сетевые задержки. Если «висит» только один отчёт или проведение одного вида документов — почти наверняка дело в запросах или коде этой операции, и серверные ресурсы тут ни при чём.

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

Шаг 2. Посмотрите, какой процесс потребляет ресурсы

Откройте диспетчер задач Windows на сервере (вкладка «Подробности») и отсортируйте процессы по загрузке процессора и памяти. В клиент-серверной архитектуре ключевые процессы: rphost — рабочие процессы сервера 1С, исполняющие код конфигурации; ragent — агент кластера; sqlservr.exe (MS SQL) или postgres — сервер СУБД. В файловом варианте вся нагрузка ложится на клиентский процесс 1cv8.exe или 1cv8c.exe.

Интерпретация простая. Если ресурсы ест rphost — нагрузку создаёт исполнение кода 1С: тяжёлые обработки, циклы, серверные вызовы. Если грузит процесс СУБД — проблема в запросах к базе: долгие выборки, отсутствие индексов, блокировки. Если процессор и память свободны, но диск загружен на 100% — узкое место в дисковой подсистеме, и усиление процессора ничего не даст.

Для более детальной картины используйте системный монитор Windows (perfmon): счётчики загрузки процессора, очереди диска, доступной памяти. Дисковая очередь, стабильно превышающая 2–3 на физический диск, — надёжный признак того, что диск не справляется с нагрузкой от базы данных.

Шаг 3. Найдите виновный сеанс через консоль кластера

В клиент-серверном варианте откройте консоль администрирования серверов 1С, перейдите в раздел «Сеансы» вашей информационной базы. Здесь видно, кто подключён, как долго длится текущий вызов сервера, сколько памяти потребляет сеанс и какой объём данных прочитан и записан. Сеанс с аномально большим временем текущего вызова или огромным количеством прочитанных записей — главный подозреваемый.

Полезные колонки: «Время вызова СУБД (текущее)», «Прочитано (текущее)», «Записано (текущее)», «Память (текущая)». Если у одного сеанса текущее чтение исчисляется гигабайтами — этот сеанс и есть источник нагрузки. По имени пользователя и приложению можно понять, кто и какую операцию запустил, и связаться с ним до принятия мер.

Шаг 4. Включите журнал регистрации и технологический журнал

Журнал регистрации (Администрирование → Обслуживание → Журнал регистрации) показывает, какие действия выполнялись в базе: проведение документов, запуск обработок, ошибки, фоновые задания. Отфильтруйте события по времени, когда наблюдались тормоза, — часто обнаруживается, что именно в этот момент стартовал массовый обмен или тяжёлая обработка.

Для глубокой диагностики используется технологический журнал (ТЖ) — он настраивается конфигурационным файлом logcfg.xml в каталоге conf сервера 1С. ТЖ фиксирует все запросы к СУБД с длительностью, события блокировок (TLOCK, TDEADLOCK), длительные вызовы. Это главный инструмент, когда нужно найти конкретный медленный запрос.

<config xmlns="http://v8.1c.ru/v8/tech-log"><log location="C:\1clogs" history="24"><event><eq property="name" value="DBMSSQL"/></event><event><eq property="name" value="TLOCK"/></event><event><eq property="name" value="TDEADLOCK"/></event><property name="all"/></log></config>

Пример выше включает запись всех запросов к MS SQL и событий блокировок в каталог C:\1clogs с хранением 24 часа. События с большим значением Duration — ваши медленные запросы; рядом в ТЖ лежит контекст: имя пользователя, сеанс, фрагмент кода конфигурации.

Шаг 5. Сделайте замер производительности конкретной операции

Если тормозит конкретный отчёт или документ, воспользуйтесь встроенным механизмом «Замер производительности» (в режиме предприятия: кнопка меню → Возможности → Замер производительности; в конфигураторе — Отладка → Замер производительности). Запустите замер, выполните медленную операцию один раз, остановите замер.

Результат покажет дерево вызовов с временем исполнения каждой строки кода и каждого запроса. Вы увидите, какая именно процедура или какой запрос занимает 90% времени. Это самый быстрый способ локализовать проблему внутри конфигурации без анализа технологического журнала.

Обратите внимание на колонку количества вызовов: если одна и та же строка кода вызвана тысячи раз, вероятен классический дефект «запрос в цикле» — запрос выполняется внутри перебора строк вместо одной выборки. Такие места дают максимальный эффект при оптимизации.

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

Шаг 6. Проверьте регламентные задания, блокировки и СУБД

Регламентные и фоновые задания — частый скрытый источник нагрузки. Откройте консоль заданий (в типовых конфигурациях: Администрирование → Обслуживание → Регламентные операции) и сопоставьте расписание с периодами тормозов. Обмены данными, расчёт итогов, полнотекстовое индексирование и загрузка курсов валют могут запускаться каждые несколько минут и конкурировать с пользователями за ресурсы.

Блокировки проявляются иначе, чем нехватка ресурсов: сервер почти простаивает, а пользователи «висят» в ожидании. В MS SQL активные блокировки видны через Activity Monitor или запросом к sys.dm_tran_locks; в 1С — через события TLOCK и TDEADLOCK технологического журнала. Типичные источники: проведение больших документов, одновременная запись в одни регистры, длительные транзакции в коде.

На стороне СУБД проверьте базовую гигиену: актуальность статистики, наличие планового обслуживания (перестроение индексов), размер и рост журнала транзакций, размещение tempdb. Запросы, которые раньше работали быстро, могут деградировать из-за устаревшей статистики — сервер начинает выбирать неудачный план выполнения.

Типичные причины нагрузки и как их подтвердить

Опыт диагностики показывает, что большинство случаев сводится к ограниченному набору причин. Подтверждать каждую нужно своим инструментом, а не по косвенным признакам.

Как проверить, что проблема решена

После устранения найденной причины обязательно выполните контрольный замер той же операции в сопоставимых условиях. Сравните время выполнения до и после: улучшение должно быть кратным, а не в пределах погрешности. Если документ проводился 40 секунд, а стал проводиться за 3 — причина устранена; если стало 35 секунд — вы убрали не главный фактор.

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

Частые вопросы