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

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

В 1С нагрузку можно оценивать на нескольких уровнях: через консоль кластера серверов, штатные средства Windows и Linux, инструменты СУБД (MS SQL Server, PostgreSQL), технологический журнал платформы и встроенные механизмы оценки производительности. Каждый инструмент отвечает на свой вопрос, и правильный выбор зависит от симптомов.

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

Что понимать под нагрузкой в 1С и какие симптомы отслеживать

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

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

Как посмотреть нагрузку в консоли кластера серверов 1С

Консоль кластера (оснастка «Администрирование серверов 1С Предприятия») — первый инструмент при диагностике. Откройте консоль, раскройте нужный кластер и последовательно посмотрите три раздела: «Сеансы», «Соединения» и «Рабочие процессы».

В разделе «Сеансы» видно, кто сейчас работает в базах, какие приложения запущены (тонкий клиент, фоновые задания, веб-сервисы), сколько памяти потребляет каждый сеанс и какова его активность. Колонки «Прочитано», «Записано», «Время вызова СУБД» помогают найти сеансы, которые генерируют основную нагрузку. Отсортируйте список по объёму прочитанных данных или времени вызова СУБД — лидеры и есть вероятные источники проблемы.

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

1. 1
   Откройте оснастку администрирования серверов 1С и выберите нужный кластер
2. 2
   Перейдите в раздел «Сеансы» и отсортируйте по времени вызова СУБД и объёму прочитанных данных
3. 3
   Зафиксируйте пользователей и фоновые задания с аномальными показателями
4. 4
   Перейдите в «Рабочие процессы» и проверьте потребление памяти каждым rphost
5. 5
   Сопоставьте тяжёлые сеансы с конкретными процессами через раздел «Соединения»

Как оценить нагрузку на сервере средствами операционной системы

На Windows откройте диспетчер задач и вкладку «Производительность»: загрузка CPU, память, диск, сеть. Для детального анализа используйте Performance Monitor (perfmon): добавьте счётчики процессора (% Processor Time), памяти (Available MBytes), диска (Avg. Disk sec/Read, Avg. Disk sec/Write) и сетевого интерфейса. Времена отклика диска выше десятков миллисекунд при активной работе базы — тревожный сигнал.

Обратите внимание, какие именно процессы потребляют ресурсы: rmngr и rphost — это сервер 1С, sqlservr — MS SQL Server, postgres — PostgreSQL. Если основную нагрузку даёт процесс СУБД, дальнейшая диагностика ведётся уже инструментами СУБД, а не 1С.

На Linux используйте top, htop, iostat, vmstat и free. Ключевые признаки проблем: высокий %iowait (процессор ждёт диск), активное использование swap, отдельные процессы rphost, упирающиеся в одно ядро.

Контрольные точки

Как отличить норму от проблемы

Загрузка CPU сервера

Норма

Средняя загрузка умеренная, пиковые всплески кратковременны и совпадают с регламентными операциями

Тревожный признак

Постоянная загрузка близко к 100% или один процесс rphost упирается в одно ядро

Оперативная память

Норма

Есть свободный объём, swap не используется активно

Тревожный признак

Память почти исчерпана, идёт активная подкачка на диск

Дисковая подсистема

Норма

Время отклика диска низкое и стабильное

Тревожный признак

Очередь диска растёт, отклик заметно увеличивается в часы пик

Как посмотреть нагрузку на стороне СУБД

Большинство «тормозов» клиент-серверной 1С находится на уровне СУБД. В MS SQL Server начните с Activity Monitor: разделы «Processes» и «Resource Waits» покажут активные запросы и типы ожиданий. Для детального анализа используйте запросы к динамическим административным представлениям sys.dm_exec_requests и sys.dm_os_wait_stats — они покажут, какие запросы выполняются прямо сейчас и чего ждёт сервер.

Долгие ожидания типа PAGEIOLATCH указывают на дисковую подсистему или нехватку памяти, LCK_* — на блокировки между транзакциями, CXPACKET — на параллелизм запросов. Блокировки в 1С-контексте часто возникают при одновременном проведении документов, затрагивающих одни регистры, и при включённых автоматических итогах на больших таблицах.

В PostgreSQL активные запросы смотрят через представление pg_stat_activity, а статистику ожиданий — через pg_stat_statements (требует включения расширения). Обратите внимание на запросы с большим accumulated временем выполнения — их текст позволит связать нагрузку с конкретными объектами конфигурации 1С.

Как использовать технологический журнал для анализа нагрузки

Технологический журнал включается файлом logcfg.xml, размещённым в каталоге conf сервера 1С. В нём задаются события для сбора: DBMSSQL или DBPOSTGRS (запросы к СУБД), CALL (вызовы), EXCP (исключения), TLOCK и TDEADLOCK (блокировки и взаимоблокировки), а также длительность событий для фильтрации.

Для поиска тяжёлых операций настройте сбор событий с порогом длительности — например, записывать только запросы дольше нескольких секунд. За время наблюдения журнал покажет, какие запросы и вызовы занимают больше всего времени, и в каком контексте они выполняются. Для разбора больших логов удобно использовать обработки-анализаторы ТЖ или штатное средство «Центр управления производительностью» (ЦУП) от фирмы «1С».

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

Как найти конкретный источник нагрузки в конфигурации

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

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

Разработчики могут использовать замеры производительности (встроенный механизм «ЗамерПроизводительности» через конфигуратор или режим отладки с замером) — он показывает, какие строки кода занимают время в конкретной операции.

Как организовать постоянный мониторинг вместо разовых проверок

Разовая диагностика решает текущий инцидент, но не предотвращает следующий. Для постоянного наблюдения настройте сбор счётчиков производительности (perfmon с сохранением в файл, Zabbix, Prometheus-экспортёры или аналогичные системы) по ключевым метрикам: CPU, память, дисковые очереди, число сеансов, время отклика СУБД.

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

Маршрут решения

Как выбрать действие по симптому

Тормоза у всех пользователей, CPU сервера СУБД под нагрузкойСмотрите активные запросы и ожидания в СУБД, ищите тяжёлый запрос и связанную операцию

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

Ошибки превышения ожидания блокировкиВключите сбор событий TLOCK/TDEADLOCK в технологическом журнале и найдите конфликтующие операции

Тормоза только у одного пользователя или филиалаПроверяйте сеть, клиентский компьютер и конкретную операцию, а не сервер

Нагрузка появляется строго по расписаниюПроверьте регламентные и фоновые задания, обмены данными и плановые операции СУБД

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

Можно ли посмотреть нагрузку в файловой базе 1С?

Консоль кластера и разделение по процессам rphost в файловом режиме недоступны. Оценивайте нагрузку через диспетчер задач на компьютере, где открыта база: смотрите процесс 1cv8 (или 1cv8c), загрузку диска и сети. Технологический журнал при этом работает и на клиенте — его можно включить для анализа тяжёлых операций.

Какой инструмент выбрать, если 1С тормозит только при формировании одного отчёта?

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

Опасно ли включать технологический журнал на рабочем сервере?

Само по себе включение безопасно, но подробный сбор событий увеличивает нагрузку на диск и может быстро заполнить том. Включайте ТЖ на ограниченное время, задавайте пороги длительности и следите за свободным местом. После диагностики отключите или сократите набор событий.

Что делать, если сеанс завис и не отвечает?

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

Как понять, что проблема в блокировках, а не в «железе»?

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

Нужны ли сторонние программы для мониторинга 1С?

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