Сервер 1С под нагрузкой: ищем виновный сеанс, процесс или запрос

Чтобы понять, кто грузит сервер 1С, сначала посмотрите в диспетчере задач, какой процесс съедает ресурсы: rphost (рабочий процесс 1С) или процесс СУБД (sqlservr.exe, postgres). Дальше по PID рабочего процесса найдите в консоли администрирования кластера его сеансы и отсортируйте их по процессорному времени текущего вызова. Обычно виновник находится за 5-10 минут: это конкретный пользователь с тяжёлым отчётом, фоновое задание или зависшая обработка.

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

С чего начать: какой процесс съедает ресурсы сервера

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

На Windows откройте «Диспетчер задач» на вкладке «Подробности» или «Монитор ресурсов» (resmon). Ещё удобнее Process Explorer из набора Sysinternals: он показывает командную строку процесса и историю загрузки. На Linux подойдут top, htop и iotop.

Процессы сервера 1С:

• 🧩 ragent — агент сервера, принимает подключения. Нагрузку почти не создаёт.
• 🗂 rmngr — менеджер кластера. Высокая загрузка бывает при большом числе сеансов или проблемах со службами кластера.
• ⚙️ rphost — рабочие процессы. Здесь выполняется код конфигурации, отчёты, проведение. Главный кандидат.
• 🗄 sqlservr / postgres — СУБД. Если грузит она, проблема в запросах, индексах или статистике.

Как читать картину

Запишите PID «горячего» rphost. Он понадобится на следующем шаге.

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

Консоль администрирования серверов 1С показывает, какие сеансы сейчас работают и сколько ресурсов они тратят. Откройте кластер и раскройте узел «Рабочие процессы». В списке есть колонка с PID — найдите процесс, который вы заметили в диспетчере задач.

Внутри рабочего процесса доступны его соединения и сеансы. Но удобнее работать сразу со списком «Сеансы» информационной базы или всего кластера.

Какие колонки включить

В списке сеансов через настройку колонок включите показатели потребления ресурсов. Платформа считает их в трёх разрезах: за текущий вызов, за последние 5 минут и за всё время сеанса.

• ⏱ время вызова (текущее) — сколько длится то, что сеанс делает прямо сейчас;
• 🧠 процессорное время за текущий вызов и за 5 минут;
• 💾 объём памяти за текущий вызов;
• 🗄 время вызовов СУБД — показывает, что сеанс ждёт базу данных, а не считает сам.

Отсортируйте по процессорному времени за 5 минут. Наверху окажется виновник. В строке сеанса видны пользователь, компьютер, приложение (тонкий клиент, фоновое задание, COM-соединение, веб-клиент) и время начала работы.

То же самое из командной строки

Утилита rac работает через сервер администрирования ras, его нужно запустить заранее. Сначала узнайте идентификатор кластера, затем выведите сеансы:

rac localhost:1545 cluster list
rac localhost:1545 session list --cluster=<uuid-кластера>
rac localhost:1545 process list --cluster=<uuid-кластера>

В выводе session list ищите поля user-name, host, app-id, а также duration-current, cpu-time-current, memory-current. Полный список полей и параметров даёт rac help session.

Мини-кейс

Сервер с 8 ядрами, нагрузка 85%. Один rphost занимает два ядра. В консоли наверху списка — сеанс бухгалтера с приложением «Тонкий клиент», время текущего вызова 14 минут. Выяснилось, что он сформировал «Анализ субконто» за три года без отбора по организации. Сеанс завершили по согласованию, отчёт переформировали за квартал — 40 секунд.

Технологический журнал: тяжёлые вызовы и их автор

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

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

Пример: писать серверные вызовы дольше 5 секунд, медленные запросы к СУБД и события управляемых блокировок.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="D:\techlog\calls" history="24">
    <event>
      <eq property="name" value="CALL"/>
      <ge property="duration" value="5000000"/>
    </event>
    <event>
      <eq property="name" value="DBMSSQL"/>
      <ge property="duration" value="1000000"/>
    </event>
    <event>
      <eq property="name" value="TTIMEOUT"/>
    </event>
    <event>
      <eq property="name" value="TDEADLOCK"/>
    </event>
    <property name="all"/>
  </log>
</config>

В 8.3 длительность указывается в микросекундах: 5000000 — это 5 секунд. Для PostgreSQL вместо DBMSSQL используйте событие DBPOSTGRS. Параметр history — сколько часов хранить файлы.

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

Что смотреть в записях

В событии CALL полезны свойства Usr (пользователь), Context (строка модуля или имя отчёта), CpuTime, Memory и MemoryPeak. В DBMSSQL — текст запроса Sql и Rows.

Быстрая выборка самых долгих вызовов на Linux:

grep -rh ',CALL,' /var/log/1c/techlog/calls | grep 'Usr=' \
  | sed -E 's/^[0-9:.]+-([0-9]+),.*Usr=([^,]*).*/\1 \2/' \
  | sort -rn | head -20

Получите список «длительность в микросекундах — пользователь». Дальше по Context видно, какой отчёт или обработка тормозит. Для регулярного анализа есть бесплатные парсеры ТЖ и платные инструменты мониторинга, но для разовой диагностики хватает grep.

Когда закончили — уберите лишние секции из logcfg.xml или удалите файл. Постоянно включённый подробный журнал сам по себе нагружает диск.

Блокировки и взаимоблокировки: процессор свободен, а работа стоит

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

Признаки блокировок:

• 🔒 ошибка Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки;
• 🔁 сообщения о взаимоблокировке при одновременном проведении документов;
• ⏳ у сеансов большое время вызова, но почти нулевое процессорное время.

Кто кого держит

В выводе rac session list есть поля blocked-by-ls (ожидание управляемой блокировки 1С) и blocked-by-dbms (ожидание блокировки СУБД). В них указан номер сеанса, который мешает. В консоли администрирования в списке сеансов для этого есть аналогичные колонки — включите их в настройке списка.

На стороне СУБД это видно так.

MS SQL Server:

SELECT session_id, blocking_session_id, wait_type, wait_time, command
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0;

PostgreSQL:

SELECT pid, pg_blocking_pids(pid) AS blocked_by, state, now() - query_start AS dur, left(query, 120)
FROM pg_stat_activity
WHERE cardinality(pg_blocking_pids(pid)) > 0;

Что обычно стоит за блокировками

• 📄 долгая транзакция: групповое перепроведение, закрытие месяца , загрузка данных в рабочее время;
• 🔁 обмен данными, который пишет в те же регистры, что и пользователи;
• 🧱 доработка, которая ставит исключительную блокировку на весь регистр без отбора;
• 🔀 автоматический режим блокировок в старой или сильно доработанной конфигурации — проверьте свойство «Режим управления блокировкой данных» в корне конфигурации.

События TTIMEOUT и TDEADLOCK из технологического журнала показывают, какие пространства блокировок и какие сеансы участвовали в конфликте. Это главный материал для программиста, который будет исправлять код.

Фоновые и регламентные задания как скрытая нагрузка

Часть нагрузки создаёт не человек, а сама база. В консоли такие сеансы видны с приложением «Фоновое задание». В типовых конфигурациях на БСП список заданий открывается через Администрирование → Обслуживание → ссылка «Регламентные и фоновые задания».

Частые источники нагрузки:

• 🔎 обновление индекса полнотекстового поиска , особенно на большой базе;
• 📑 извлечение текста из присоединённых файлов;
• 🔄 обработчики отложенного обновления после установки нового релиза — могут работать часами;
• 🔁 обмены данными по расписанию каждые 1-5 минут;
• 📬 загрузка документов ЭДО, курсов валют, классификаторов.

Что можно сделать:

1. Посмотрите расписание тяжёлых заданий и перенесите их на ночь.
2. Обмен «раз в минуту» замените разумным интервалом — 10-15 минут обычно хватает.
3. Индекс полнотекстового поиска обновляйте реже или отключите поиск, если им никто не пользуется.
4. В копиях базы (тестовых, отладочных) включите в свойствах информационной базы в консоли флаг «Блокировка регламентных заданий включена». Иначе копия будет параллельно выполнять обмены и загрузки рабочей базы.

Оптимизация СУБД: статистика, индексы, память

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

MS SQL Server

• 📊 Обновление статистики — ежедневно ночью. Устаревшая статистика заставляет оптимизатор выбирать плохой план: запрос, который шёл секунду, начинает идти минуту.
• 🧹 Обслуживание индексов — реорганизация или перестроение раз в неделю. Сильно фрагментированные индексы читаются медленнее.
• 🧠 Ограничение памяти (max server memory). Без него SQL Server забирает почти всю память, и rphost на том же сервере уходят в своп.
• 🗃 tempdb — на быстром диске, несколько файлов данных одинакового размера.
• 🧽 Очистка процедурного кэша после обновления статистики — по рекомендациям для 1С это часть ночного регламента.

PostgreSQL

• 🧹 автоочистка (autovacuum) должна быть включена; на больших таблицах её пороги снижают;
• 📊 после загрузки или массовых изменений выполните VACUUM ANALYZE;
• 🧠 shared_buffers обычно ставят около четверти оперативной памяти, effective_cache_size — с учётом кэша ОС;
• 🧾 используйте сборку PostgreSQL, рекомендованную для 1С: в ней есть доработки под запросы платформы.

Средствами 1С

В конфигураторе через Администрирование → Тестирование и исправление есть пункт «Реиндексация таблиц информационной базы». Эта операция требует монопольного доступа к базе, поэтому выполняйте её только ночью и после резервной копии. Для клиент-серверной базы обслуживание средствами СУБД обычно удобнее и быстрее.

Параметры рабочего сервера

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

Как не допустить повторения

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

1. Держите облегчённый технологический журнал: только CALL дольше 10-20 секунд, TTIMEOUT и TDEADLOCK, хранение 24-48 часов. Нагрузка от него небольшая, а при жалобе данные уже есть.
2. Настройте в консоли кластера счётчики потребления ресурсов по базам или пользователям, если на одном кластере работает несколько баз.
3. Отслеживайте загрузку процессора, памяти и очередь диска средствами мониторинга ОС (Zabbix, системный монитор производительности Windows).
4. Договоритесь с пользователями: тяжёлые отчёты за несколько лет и групповое перепроведение — не в разгар рабочего дня.
5. Новые доработки проверяйте на копии базы с реальным объёмом данных, а не на пустой демонстрационной.

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

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