Как увидеть нагрузку на 1С и найти её источник

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

Если 1С «тормозит», важно не угадывать, а измерить: процессор, оперативная память, диск и ожидания на блокировках ведут себя по-разному, и лечатся они тоже по-разному. Ниже — где именно смотреть каждую метрику в клиент-серверном варианте (платформа 8.3), как читать технологический журнал и чем снять нагрузку, когда источник найден.

Разбор рассчитан на клиент-серверную базу (сервер 1С + СУБД). В файловом варианте «нагрузку» по сути смотрят только через диспетчер задач процесса 1cv8.exe и монитор ресурсов ОС — своего кластера там нет.

С чего начать: какую нагрузку вообще ищем

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

• 🧮 Процессор (CPU). Один-два ядра в полке — обычно «тяжёлый» запрос или фоновое задание. Смотрим рабочие процессы rphost в диспетчере задач.
• 🧠 Память (RAM). Процесс rphost разрастается до нескольких гигабайт — утечки, большие выборки, незакрытые итераторы. Контролируем в консоли кластера.
• 💽 Диск. Высокая очередь и задержки на дисках чаще на стороне СУБД, а не сервера 1С.
• ⏳ Ожидания. Пользователи «висят», а процессор свободен — это блокировки: управляемые в 1С или на уровне СУБД.

Быстрый способ понять, где узкое место, — сопоставить симптом с инструментом.

Технологический журнал платформы: что в нём смотреть

Технологический журнал (ТЖ) — главный встроенный инструмент диагностики платформы. Он пишет текстовые логи по событиям, которые вы сами включаете в файле настройки.

Настройка задаётся в файле logcfg.xml. Его кладут в каталог conf установленной платформы — например, C:\Program Files\1cv8\conf\. Платформа подхватывает изменения на лету, перезапуск службы не нужен.

Минимальный конфиг, который ловит долгие вызовы и ошибки:

<?xml version="1.0"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\logs\techlog" history="24">
    <event>
      <ne property="name" value=""/>
    </event>
    <property name="all"/>
  </log>
</config>

Параметр history — сколько часов хранить логи, location — куда писать (кладите на отдельный диск, журнал пишет много). После диагностики ТЖ обязательно отключайте: на нагруженной базе полный сбор сам по себе съедает ресурсы и место.

Какие события включать под конкретную задачу:

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

Нагрузка на кластере серверов: сеансы, процессы, память

Основной «пульт» клиент-серверной базы — оснастка Администрирование серверов 1С:Предприятия. Она показывает кластер в реальном времени.

Что смотреть в консоли:

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

Те же данные можно снять из командной строки утилитой администрирования rac (сервер администрирования ras должен быть запущен). Безопасные для чтения команды:

rac cluster list
rac session list --cluster=<идентификатор кластера>
rac process list --cluster=<идентификатор кластера>

rac process list выводит потребление памяти рабочими процессами, rac session list — активные сеансы. Полный список параметров всегда под рукой: rac help. Не придумывайте ключи по памяти — лучше свериться со справкой, чем ошибиться.

Отдельно задайте разумные лимиты на уровне кластера: предельный объём памяти рабочих процессов, через который «тяжёлый» процесс будет перезапущен, и интервал превышения. Это не лечит причину, но спасает от падения всего сервера из-за одного зарвавшегося сеанса.

Анализ на стороне СУБД: долгие запросы и блокировки

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

Для Microsoft SQL Server:

• Монитор активности (Activity Monitor) в SQL Server Management Studio — обзор процессора, ожиданий и дорогих запросов в реальном времени.
• Представление sys.dm_exec_query_stats в связке с sys.dm_exec_sql_text — топ запросов по суммарному времени и чтениям.
• sys.dm_os_wait_stats — на чём именно сервер ждёт (диск, блокировки, память).
• Расширенные события (Extended Events) или отчёт о заблокированных процессах — для разбора взаимоблокировок.

Для PostgreSQL:

• Представление pg_stat_activity — активные запросы прямо сейчас, их состояние и время старта.
• Расширение pg_stat_statements — накопленная статистика по запросам (суммарное и среднее время).
• Параметр log_min_duration_statement — логировать всё, что выполняется дольше заданного порога (например, 3 секунды).

Сопоставляйте находки с технологическим журналом по тексту SQL: события DBMSSQL/DBPOSTGRS в ТЖ 1С и топ дорогих запросов в СУБД обычно указывают на один и тот же проблемный объект метаданных. Текст SQL от 1С выглядит нечитаемо (имена таблиц вида _Document123), но по контексту вызова в журнале почти всегда понятно, какой документ или регистр за этим стоит.

Отдельно разделяйте два типа блокировок. Управляемые блокировки 1С видны в событиях TLOCK/TTIMEOUT технологического журнала — это логика самой платформы, когда два пользователя правят одни данные. Блокировки на уровне СУБД видны в её инструментах и возникают из-за долгих транзакций и неоптимальных запросов. Лечатся они по-разному: первые — пересмотром бизнес-логики и режима блокировок, вторые — ускорением запросов.

Три самых частых причины нагрузки на СУБД:

• 📉 устаревшая статистика и фрагментированные индексы — регламентное обслуживание не настроено;
• 🔑 отсутствие подходящего индекса под частый запрос — полное сканирование таблицы;
• 🧊 нехватка оперативной памяти под кэш данных — СУБД постоянно читает с диска.

Встроенная оценка производительности в конфигурации

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

Включается в разделе Администрирование → Оценка производительности (точное название пункта может отличаться между конфигурациями на БСП). После включения система копит замеры, а итог сводится в отчёт, где каждая операция получает оценку APDEX от 0 до 1.

Как это читать:

• 0,85–1,0 — операция работает отлично;
• 0,7–0,85 — приемлемо;
• ниже 0,7 — пользователи реально страдают, разбирайтесь с этой операцией.

Ценность подхода в том, что он отвечает на главный вопрос бизнеса: «где именно людям медленно работать», а не просто «процессор загружен на 80%». Начинайте оптимизацию с операций, у которых низкий APDEX и большое число вызовов.

Для серьёзного нагрузочного анализа существуют отдельные инструменты из корпоративного инструментального пакета 1С (центр управления производительностью, тест-центр). Это уже тяжёлая артиллерия для проектов с сотнями пользователей, но работает она поверх того же технологического журнала.

Внешний мониторинг: счётчики ОС и Zabbix

Чтобы видеть нагрузку постоянно, а не ловить её вручную, подключают внешний мониторинг. Он собирает метрики круглосуточно и шлёт оповещения до того, как пользователи напишут «всё зависло».

Базовый уровень — счётчики производительности операционной системы. На Windows их смотрят в «Системном мониторе» (Performance Monitor). Минимальный набор для сервера 1С и СУБД:

• Процессор\% загруженности процессора — общая загрузка CPU;
• Память\Доступно МБ — свободная оперативная память;
• Физический диск\Среднее время чтения/записи — задержки диска (критично для СУБД);
• потребление памяти и процессора конкретно процессами rphost и процессом СУБД.

Следующий уровень — система мониторинга вроде Zabbix. Она хранит историю, строит графики и шлёт алерты. Для 1С обычно собирают:

• 🖥️ метрики ОС через агент Zabbix (CPU, RAM, диск, сеть);
• ⚙️ данные кластера через утилиту rac (число сеансов, память рабочих процессов) — Zabbix периодически вызывает rac и парсит вывод;
• 🗄️ метрики СУБД через её шаблон (число соединений, долгие запросы, блокировки).

Такой стенд даёт ретроспективу: когда в понедельник в 9:00 сервер «встаёт», вы открываете график и видите, какое именно задание или отчёт запускает пик. Это снимает половину вопросов ещё до разбора журналов.

Как снизить нагрузку, когда источник найден

Диагностика без действий бессмысленна. Когда понятно, что именно грузит систему, работают по уровням — от быстрого к серьёзному.

Регламенты и организация. Самый дешёвый выигрыш:

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

Оптимизация запросов и кода. Когда найден конкретный долгий запрос:

• добавьте отборы и не читайте лишние реквизиты и таблицы;
• проверьте, есть ли подходящий индекс под условие запроса;
• избегайте запросов в цикле — собирайте данные одной выборкой.

Железо и масштабирование. Когда код уже оптимален, а нагрузка объективно выросла:

• добавьте оперативной памяти серверу СУБД — это почти всегда даёт лучший эффект на рубль;
• перенесите сервер 1С и СУБД на разные физические машины или быстрые диски (SSD/NVMe);
• при десятках активных пользователей поднимите несколько рабочих процессов в кластере, чтобы нагрузка распределялась.

Главное правило порядка: сначала измерьте, потом меняйте, затем снова измерьте. Добавлять память или ядра «на всякий случай», не найдя источник, — частая и дорогая ошибка. Нередко один неоптимальный запрос или неиндексированный отбор грузит сервер сильнее, чем сотня пользователей, и его исправление снимает проблему без всякого апгрейда железа.

Чек-лист быстрой диагностики, когда «всё тормозит прямо сейчас»:

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