Проверка сервера 1С Предприятие: от нагрузки на ОС до техжурнала

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

Проверка сервера 1С Предприятие занимает 30-40 минут, если идти по списку. Ниже порядок, который работает и для файлового кластера на Windows, и для Linux с PostgreSQL. Все команды безопасны: они только читают данные.

С чего начать проверку сервера 1С: быстрый маршрут

Сначала решите, какой у вас случай. От этого зависит, куда смотреть в первую очередь.

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

Что смотреть на уровне операционной системы

Здесь отвечаем на один вопрос: хватает ли машине ресурсов. Серверу 1С нужны процессор, оперативная память и быстрый диск. Сеть важна между сервером приложений и СУБД.

Windows

Откройте «Диспетчер задач», вкладка «Производительность», и посмотрите три вещи. Для серьёзной картины запустите perfmon и добавьте счётчики:

Счётчики собирайте хотя бы час в рабочее время. Мгновенный снимок обманчив: пик может прийти и уйти за минуту.

Linux

Хватит стандартных утилит:

top -b -n 1 | head -20          # процессы и общая загрузка
free -m                          # память и своп
vmstat 5 5                       # очередь процессов, своп, ожидание диска
iostat -x 5 3                    # загрузка и задержки дисков
df -h                            # место на разделах

В vmstat смотрите колонки si и so: если они не нулевые, сервер уходит в своп, и это уже беда. В iostat важны await и %util: диск с %util около 100% и растущим await не справляется.

Отдельные проверки, о которых забывают

• 🕒 Время: на сервере 1С, сервере СУБД и у клиентов оно должно совпадать, иначе разбор журналов превратится в мучение.
• 🌐 Сеть между сервером 1С и СУБД: задержка в пределах миллисекунды, потерь пакетов нет. Проверьте ping с большим числом пакетов.
• 💾 Антивирус: исключите из проверки каталоги данных СУБД и служебные каталоги кластера, иначе антивирус даёт заметную нагрузку на диск.
• ⚡ Схема электропитания Windows: у серверов должен стоять режим «Высокая производительность», а не «Сбалансированная».

Состояние кластера: рабочие процессы, сеансы, соединения

Если ОС в порядке, переходим к самому кластеру. Откройте консоль кластера 1С («Администрирование серверов 1С Предприятия») и раскройте нужный центральный сервер.

Три процесса, которые стоит знать

• ragent — агент сервера. Запускает остальное и отвечает за связь кластера с клиентами.
• rmngr — менеджер кластера. Хранит реестр сеансов, управляет блокировками и распределяет клиентов по рабочим процессам.
• rphost — рабочий процесс. Именно здесь выполняется код конфигурации и ест память.

Если на сервере несколько рабочих процессов, нагрузка распределена между ними. Один rphost, раздувшийся до десятков гигабайт, — частая причина зависаний.

Что проверять в консоли

1. Откройте «Рабочие серверы» и проверьте допустимое количество процессов и лимиты памяти.
2. В ветке «Рабочие процессы» посмотрите колонки с потреблением памяти, числом соединений и «Доступная производительность». Значение доступной производительности около 100 — процесс свободен, близко к нулю — перегружен.
3. В «Сеансах» найдите долгие вызовы. Для сеанса видно, какой вызов выполняется, сколько он длится и сколько памяти занял.
4. В «Соединениях» убедитесь, что нет «зависших» соединений от уже закрытых клиентов.

Серверная часть консоли показывает не всё. Для автоматического сбора пользуйтесь утилитой администрирования rac:

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

Для работы rac должна быть запущена служба ras (сервер администрирования). Перед запуском проверьте порт и доступ: по умолчанию служба слушает порт 1545.

Лимиты рабочих процессов

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

Что даёт журнал регистрации при проверке сервера

Журнал регистрации — это журнал изменений данных и действий пользователей в конкретной информационной базе. Для диагностики сервера он полезен косвенно, но полезен.

Откройте его в режиме «Конфигуратор» (меню «Администрирование» — «Журнал регистрации») или в режиме «1С:Предприятие» через раздел администрирования. Затем:

1. Отберите записи с уровнем «Ошибка» и «Предупреждение» за период жалоб.
2. Обратите внимание на события входа и «Сеанс. Аутентификация»: частые неудачные попытки означают проблему с учётными записями или лишние обращения.
3. Найдите события «Фоновое задание. Ошибка выполнения» и регламентные задания. Зависшее или падающее задание нередко и есть источник нагрузки.
4. Отдельно посмотрите события о блокировках и «Транзакция. Отмена»: отмены в большом числе указывают на конфликты в данных.

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

Блокировки и транзакции: проверка на стороне СУБД

Блокировки бывают двух видов, и путать их нельзя. Управляемые блокировки создаёт сама 1С, их видно в консоли кластера (вкладка «Блокировки» у информационной базы). Блокировки СУБД ставит сервер базы данных, и увидеть их можно только запросами.

PostgreSQL

Кто кого блокирует, покажет такой запрос:

SELECT a.pid,
       a.usename,
       a.state,
       now() - a.xact_start AS xact_age,
       pg_blocking_pids(a.pid) AS blocked_by,
       left(a.query, 120) AS query
FROM pg_stat_activity a
WHERE cardinality(pg_blocking_pids(a.pid)) > 0;

Если нужен список «долгих» транзакций, отсортируйте pg_stat_activity по xact_start. Транзакция, открытая часами в состоянии idle in transaction, держит блокировки и мешает очистке мёртвых строк.

Microsoft SQL Server

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

Цепочку блокировок читайте от корня: сеанс, который блокирует других, но сам никем не блокируется, — виновник. Тип ожидания (wait_type) подскажет причину: ожидание диска, ожидание блокировки и так далее.

Как связать сеанс СУБД с пользователем 1С

В консоли кластера у соединения указан его номер и идентификатор подключения к СУБД. Сопоставьте этот идентификатор с pid (PostgreSQL) или session_id (MS SQL). Так вы увидите, чей именно сеанс держит блокировку и в какой информационной базе.

Управляемые блокировки 1С

Сообщение «Превышено время ожидания предоставления блокировки» относится к управляемым блокировкам: за ними стоят конкретные пространства блокировок и поля. В консоли откройте блокировки базы и найдите сеанс-владельца. Подробности даёт технологический журнал с событиями TLOCK, TTIMEOUT и TDEADLOCK.

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

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

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

1. Найдите каталог conf в каталоге установки платформы. Файл называется logcfg.xml.
2. Создайте или откройте этот файл и опишите, какие события писать и куда.
3. Перезапускать службу обычно не нужно: платформа перечитывает настройки сама.
4. После диагностики файл верните в исходное состояние. Иначе журнал разрастётся и займёт диск.

Минимальный пример: писать долгие вызовы сервера и исключения.

<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="http://v8.1c.ru/v8/tech-log">
  <log location="C:\1clogs\tech" history="24">
    <event>
      <eq property="name" value="CALL"/>
      <ge property="duration" value="3000000"/>
    </event>
    <event>
      <eq property="name" value="EXCP"/>
    </event>
    <property name="all"/>
  </log>
</config>

Длительность в техжурнале хранится в микросекундах, поэтому 3000000 — это 3 секунды. Параметр history задаёт, сколько часов хранить файлы.

Какие события читать

Файлы техжурнала лежат в подкаталогах по типу процесса и номеру. Искать удобно по тексту: grep -r "TTIMEOUT" /var/log/1c-tech в Linux или поиск по содержимому в Windows. Для разбора больших объёмов используют специальные утилиты и скрипты, о чём речь ниже.

Автоматизация: скрипты и регулярные проверки

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

Что стоит мониторить постоянно

• 📈 Загрузка процессора, память и диск на обеих машинах: сервере 1С и сервере СУБД.
• 🧠 Потребление памяти каждым rphost: рост без возврата означает утечку или подвисший процесс.
• 🔌 Число сеансов и лицензий: упёрлись в лимит — новые пользователи не войдут.
• 💽 Свободное место под базу, журналы и резервные копии.
• ⏰ Время выполнения регламентных заданий.

Пример: ежедневный сбор данных через rac

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

#!/bin/bash
CLUSTER="<идентификатор_кластера>"
OUT="/var/log/1c-monitor/rphost_$(date +%F).log"
echo "=== $(date '+%F %T') ===" >> "$OUT"
rac process list --cluster="$CLUSTER" >> "$OUT"

Запускайте скрипт из cron. Для Windows аналог — запуск rac.exe из планировщика заданий с перенаправлением вывода в файл.

Готовые системы мониторинга

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

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