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

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

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

Ниже разобран практический порядок действий: от быстрой проверки через консоль кластера до анализа технологического журнала и счётчиков SQL Server или PostgreSQL. Материал ориентирован на администраторов и внедренцев, работающих с клиент-серверной 1С.

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

Первый шаг — понять, какой узел страдает. Откройте диспетчер задач на сервере 1С и сервере СУБД (если они разнесены). Если процесс rphost потребляет много CPU и памяти — нагрузка идёт от исполнения кода и запросов через рабочие процессы кластера. Если загружен процесс СУБД (sqlservr, postgres), а rphost почти простаивает — проблема в запросах, индексах или блокировках на уровне базы данных.

Если оба сервера загружены умеренно, но пользователи жалуются на «подвисания», проверьте сеть между серверами и дисковую подсистему. Дисковая очередь выше 2–3 на длительном интервале — признак того, что СУБД упирается в чтение/запись, и «виноват» может быть не конкретный пользователь, а общая архитектура хранения.

Консоль кластера: находим тяжёлые сеансы

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

Обратите внимание на колонку «Приложение»: она показывает, чем занят сеанс — тонкий клиент пользователя, фоновое задание, COM-соединение или веб-сервис. Если вверху списка регулярно оказывается фоновое задание, смотрите, какое регламентное задание оно выполняет и как часто запускается.

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

1. 1
   Откройте консоль серверов 1С и ветку «Сеансы» нужной базы
2. 2
   Отсортируйте по «Прочитано (текущее)» и «Время вызова СУБД (текущее)»
3. 3
   Определите приложение и пользователя в верхних строках
4. 4
   Снимите для подозрительного сеанса дамп вызовов или посмотрите связанное фоновое задание
5. 5
   Повторите наблюдение через 5–10 минут и сравните рост счётчиков

Технологический журнал: когда консоли недостаточно

Консоль показывает моментальный срез, но не объясняет, какой именно запрос или участок кода создаёт нагрузку. Для этого включают технологический журнал (ТЖ) — логирование событий платформы через файл logcfg.xml, размещённый в каталоге conf сервера.

Настройте отбор по длительным событиям: например, фиксировать DBMSSQL или DBPOSTGRS длительностью более 1–2 секунд, а также события EXCP (исключения) и TLOCK/TDEADLOCK (блокировки и взаимоблокировки). Такой фильтр не перегружает диск и сразу показывает проблемные запросы с контекстом — именем пользователя, номером соединения и текстом запроса.

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

Диагностика на стороне СУБД

Если нагрузка сосредоточена в базе данных, смотрите активность штатными средствами СУБД. В Microsoft SQL Server откройте Activity Monitor в SQL Server Management Studio или выполните запрос к sys.dm_exec_requests с соединением к sys.dm_exec_sql_text — так видно выполняющиеся запросы, их длительность, ожидания и логины. Подозрительны запросы с большим количеством логических чтений и длительным ожиданием блокировок.

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

Отдельно проверьте блокировки: взаимоблокировки и длительные ожидания часто «грузят» сервер косвенно — сеансы висят, рабочие процессы заняты, пользователи видят зависания. В ТЖ 1С этим ситуациям соответствуют события TLOCK, TTIMEOUT и TDEADLOCK с указанием таблиц и соединений.

SELECT r.session_id, r.status, r.wait_type, r.total_elapsed_time, t.text FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t WHERE r.session_id > 50 ORDER BY r.total_elapsed_time DESC;

Типичные виновники нагрузки

На практике список источников нагрузки повторяется от базы к базе. Чаще всего встречаются: регламентные и фоновые задания с слишком частым расписанием (обмены каждую минуту, пересчёт итогов днём), тяжёлые отчёты без отборов, которые пользователи запускают по всей базе за весь период, и обмены данными с другими системами через COM и веб-сервисы.

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

Что делать с найденным источником

Действие зависит от типа виновника. Тяжёлый отчёт — ограничьте обязательными отборами по периоду и организации, вынесите его выполнение в фоновое задание на нерабочее время. Частое регламентное задание — пересмотрите расписание: многие обмены достаточно выполнять раз в 5–15 минут или по событию, а не каждую минуту.

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

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

Профилактика: как не искать виновника вручную каждый раз

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

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

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

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